From: T. M. <x...@ve...> - 2007-07-12 15:59:36
|
Since switching from GIST to GIN i've been noticing the subject of this message in my logs. It turns out that the queries generating the error contained only stop words, which of course were removed during the to_tsquery() call, leaving the null query. For my application I have a few solutions to consider: - have the application remove stop words before sending query, leave out the @@ constraint in the case that a blank string is left there - catch the exception coming back from postgresql and if it contains this error message, remove the @@ constraint and requery (this may not be a bad solution as it's a fairly rare event) - execute a to_tsquery(...) and check for NULL return, and make changes if necessary, before executing search query (i tend to not like this solution as it executes an extra query for every search) But I'm wondering about this behavior of GIN. I didn't notice this with GIST. What was GIST's behavior? It seems to me in a search application, at least, the default behavior when searching for an empty string is to return all documents. Though this is somehwat arbitrary, especially in the case that a stop word has been removed (though ironically in the case I discovered this with the stop word that was removed was actually "all"!). Anyhow, i just wanted to share my experience with this in case someone here with more experience than I thinks the default behavior should be changed here for TSearch2. Having a empty string query throw an exception/crash the application, doesn't seem very agreeable to me. |