Simon Riggs wrote:
> On Mon, 2007-11-12 at 11:56 -0500, Tom Lane wrote:
> > 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".
>
> Most people don't understand those differences. x = y means "make sure
> they are the same" to most people. They don't see what you (and I) see:
> function and operator interchangeability. So text_search() is better
> than @@ and = is better than texteq(). Life ain't neat...
>
> Right now, Full Text Search SQL looks like complete gibberish and it
> dissuades many people from using what is an awesome set of features. I
> just want to add a little sugar to help people get started.
I realized this when editing the documentation but not clearly. I
noticed that:
http://momjian.us/main/writings/pgsql/sgml/textsearch-intro.html#TEXTSEARCH-MATCHING
tsvector @@ tsquery
tsquery @@ tsvector
text @@ tsquery
text @@ text
The first two of these we saw already. The form text @@ tsquery is
equivalent to to_tsvector(x) @@ y. The form text @@ text is equivalent
to to_tsvector(x) @@ plainto_tsquery(y).
was quite odd, especially the "text @@ text" case, and in fact it makes
casting almost required unless you can remember which one is a query and
which is a vector (hint, the vector is first). What really adds to the
confusion is that the operator is two _identical_ characters, meaning
the operator is symetric, and it behave symetric if you cast one side,
but as vector @@ query if you don't.
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
