Gregory Stark wrote: > "Bruce Momjian" <[EMAIL PROTECTED]> writes: > > > Gregory Stark wrote: > >> "Bruce Momjian" <[EMAIL PROTECTED]> writes: > >> > >> > 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? > >> > >> When you try storing a tsquery in a column does it alert you if you have an > >> invalid syntax at that point? Storing it as text would mean not finding out > >> until you try to use the query. > > > > Yes it does check syntax: > > > > test=> select 'lkjadsf kjfdsa'::tsquery; > > ERROR: syntax error in tsearch query: "lkjadsf kjfdsa" > > > > A larger question is how many people store queries in the database to > > make it worth the complexity. > > So would this still happen if you didn't have a tsquery type? Or would it > throw the error only when the actual matching operator executed and tried to > parse the text?
Well, if you didn't have a tsquery data type then you would get the error when the TEXT was cast to tsquery for the search itself. > >> Is converting a text query into the internal format faster or less memory > >> intensive than converting text into the internal representation? When you > >> run > >> a query like "WHERE '...' @@ col" if there wasn't a tsquery data type then > >> '...' would have to be parsed over and over again for each row. > > > > No, internally the TEXT string would be converted to something the > > system could deal with for that query, which is probably what 99% of all > > queries are going to do anyway by calling to_tsquery(). > > How would that happen if there wasn't a tsquery type? There is an internal C structure which holds the tsquery information. My guess is that we would internally have something like tsquery but it wouldn't be user-visible perhaps. Right now I am a little confused about how to do this and keep the data-type-independent nature of the backend. You are right that we might have to end up re-parsing the TEXT field every time it hits the @@ operator, which is a pain. -- 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 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
