"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> Simon Riggs <simon@2ndquadrant.com> 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
