Tom Lane wrote:
> Bruce Momjian <bruce@momjian.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@momjian.us> http://momjian.us EnterpriseDB
http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
