"Tom Lane" <[EMAIL PROTECTED]> writes: > Simon Riggs <[EMAIL PROTECTED]> writes: >> So we end up with a normal sounding function that is overloaded to >> provide all of the various goodies. > > As best I can tell, @@ does exactly this already. This is just a > different spelling of the same capability, and I don't actually > find it better. Why is "text_search(x,y)" better than "x @@ y"? > We don't recommend that people write "texteq(x,y)" instead of > "x = y".
I agree, I find it odd to suggest that a function would be more natural than an operator. The main reason the non-core version of tsearch felt so much like an add-on was precisely that it had to use functions to interface with objects. That Postgres supports creating new operators is a strength which allows a lot more extensibility. And yet I agree that there's something awkward about the tsearch syntax. I'm not sure where the core of it comes from though, but I don't think it comes from the use of operators. Part of it is that "@@" isn't a familiar operator. I'm not even sure what to read it as. "Matches"? "Satisfies"? Perhaps we should think (at some point in the future) about some way of allowing alphabetic characters in operator names. Then you could write something like: col ~satisfies~ '1 & 2' (That exact syntax wouldn't work without removing ~ from the characters in normal operators so something with more finesse would be needed.) The other part of tsearch that seems somewhat awkward is just the very concept and syntax of tsqueries. But that seems pretty integral to the functionality and I don't see any way to avoid it. It's not entirely unlike the idea of regexps which I'm sure would seem unnatural if we were just meeting them with no background. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
