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]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + 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