Re: new function for tsquery creartion

> I'm not sure about the different result for these queries:
> SELECT websearch_to_tsquery('simple', 'cat or ');
>  websearch_to_tsquery
> ----------------------
>  'cat'
> (1 row)
> SELECT websearch_to_tsquery('simple', 'cat or');
>  websearch_to_tsquery
> ----------------------
>  'cat' & 'or'
> (1 row)

I guess both queries should produce just 'cat'. I've changed the 
definition of parse_or_operator().

> I found an odd behavior of the query creation function in case:
> SELECT websearch_to_tsquery('english', '"pg_class pg"');
>     websearch_to_tsquery
> -----------------------------
>  ( 'pg' & 'class' ) <-> 'pg'
> (1 row)
> 
> This query means that lexemes 'pg' and 'class' should be at the same
> distance from the last 'pg'. In other words, they should have the same
> position. But default parser will interpret pg_class as two separate
> words during text parsing/vector creation.
> 
> The bug wasn't introduced in the patch and can be found in current
> master. During the discussion of the patch with Dmitry, he noticed that
> to_tsquery() function shares same odd behavior:
> select to_tsquery('english', ' pg_class <-> pg');
>          to_tsquery
> -----------------------------
>  ( 'pg' & 'class' ) <-> 'pg'
> (1 row)

I've been thinking about this for a while, and it seems that this should 
be fixed somewhere near parsetext(). Perhaps 'pg' and 'class' should 
share the same position. After all, somebody could implement a parser 
which would split some words using an arbitrary set of rules, for 
instance "split all words containing digits". I propose merging this 
patch provided that there are no objections.

-- 
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company