Re: Why is there a tsquery data type?

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> 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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

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