Re: [HACKERS] Rethinking our fulltext phrase-search implementation

Artur Zakirov writes: > Otherwise it seems that queries like 'a <-> (b & c)' will always return > false. Then we need maybe some warning message. Well, the query as written is pointless, but it could be useful with something other than "b" and "c" as the AND-ed terms.

Re: [HACKERS] Rethinking our fulltext phrase-search implementation

Hello Tom, On 17.12.2016 21:36, Tom Lane wrote: 4. The transformations are wrong anyway. The OR case I showed above is all right, but as I argued in <24331.1480199...@sss.pgh.pa.us>, the AND case is not: regression=# select 'a <-> (b & c)'::tsquery; tsquery

Re: [HACKERS] Rethinking our fulltext phrase-search implementation

I wrote: > I've been thinking about how to fix the problem Andreas Seltenreich > reported at > https://postgr.es/m/87eg1y2s3x@credativ.de Attached is a proposed patch that deals with the problems discussed here and in <26706.1482087...@sss.pgh.pa.us>. Is anyone interested in reviewing this,

Re: [HACKERS] Rethinking our fulltext phrase-search implementation

I wrote: > It's worth noting that with these rules, phrase searches will act as > though "!x" always matches somewhere; for instance "!a <-> !b" will match > any tsvector. I argue that this is not wrong, not even if the tsvector is > empty: there could have been adjacent stopwords matching !a and

[HACKERS] Rethinking our fulltext phrase-search implementation

I've been thinking about how to fix the problem Andreas Seltenreich reported at https://postgr.es/m/87eg1y2s3x@credativ.de The core of that problem is that the phrase-search patch attempts to restructure tsquery trees so that there are no operators underneath a PHRASE operator, except