Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?
Date
Msg-id 1828.1465405920@sss.pgh.pa.us
Whole thread Raw
In response to Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?  (Jean-Pierre Pelletier <jppelletier@e-djuster.com>)
Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?  (Oleg Bartunov <obartunov@gmail.com>)
List pgsql-hackers
Another thing I noticed: if you test with tsvectors that don't contain
position info, <-> seems to reduce to &, that is it doesn't enforce
relative position:

regression=# select 'cat bat fat rat'::tsvector @@ 'cat <-> rat'::tsquery;?column? 
----------t
(1 row)

regression=# select 'rat cat bat fat'::tsvector @@ 'cat <-> rat'::tsquery;?column? 
----------t
(1 row)

I'm doubtful that this is a good behavior, because it seems like it can
silently mask mistakes.  That is, applying <-> to a stripped tsvector
seems like user error to me.  Actually throwing an error might be too
much, but perhaps we should make such cases return false not true?

(This is against HEAD, without the patch I suggested yesterday.
It strikes me that that patch might change this behavior, if the
lexemes are all being treated as having position zero, but I have
not checked.)
        regards, tom lane



pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: Precedence of new phrase search tsquery operator
Next
From: Bruce Momjian
Date:
Subject: Use of index for 50% column restriction