Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?
От | Tom Lane |
---|---|
Тема | Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ? |
Дата | |
Msg-id | 1828.1465405920@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Should phraseto_tsquery('simple', 'blue blue') @@
to_tsvector('simple', 'blue') be true ?
Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ? |
Список | 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 по дате отправления: