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. In this usage
"&" is equiv
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
-
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, o
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
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 possibly