Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> By that logic, we don't need any data types other than text.
> > What is tsquery giving us that text would not?
> A preprocessed representation that can be compared to tsvector
> efficiently.
> Now, if you'd asked whether we need *both* tsvector and tsquery,
> that'd be a fair question.  I'm not 100% clear on what the differences
> are, but they seem pretty subtle.  Do you think that having only
> one datatype would be clearer?

There is no question things would be clearer with only one text search
data type.  The only value I can see to having a tsquery data type is
that you can store a tsquery value in a column, but why would that be
much better than just storing it in a TEXT field?

Internally I assume you would have to generate a tsquery structure from
a TEXT string, so the idea of a query representation wouldn't go away;
it would just be internal.

The one thing we would lose is the ability to process the query string
with a named configuration.  If we always cast to TEXT, I assume we
would always be using "default_text_search_config", and I am a little
worried about queries in triggers that have to wire-down the
configuration name.  As I understand it the tsquery goes through the
configuration just like the tsvector.

Right now you can already do:

        'query' @@ 'boy girl'::tsvector

and the system casts your text string to tsquery automatically.  Perhaps
we just need to minimize tsquery in the documentation and mention its
special purpose.

  Bruce Momjian  <[EMAIL PROTECTED]>

  + If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to