Re: BUG #17542: tsquery returns incorrect results with nested, conjuncted followed-by operators - Mailing list pgsql-bugs

From Jordan Lewis
Subject Re: BUG #17542: tsquery returns incorrect results with nested, conjuncted followed-by operators
Date
Msg-id CAALgziLmeNuaq60j4nBptd0knoj80C+=Ks06pAK68wYf44gz+A@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17542: tsquery returns incorrect results with nested, conjuncted followed-by operators  (Pavel Borisov <pashkin.elfe@gmail.com>)
List pgsql-bugs
On Mon, Jul 11, 2022, 08:35 Pavel Borisov <pashkin.elfe@gmail.com> wrote:
I guess this result is derived from the agreement that logical operation inside the phrase operator is treated as 
"both operands a and b are in the _same_ position just before c".

select '(a & b) <-> c'::tsquery @@ 'a:1 b:1 c:2';
 ?column?
----------
 t
(1 row)

Though it's not clear what it means if there is another phrase operator inside logical. Result positions of (a <2> c) and (b <-> c) are different, I guess. It's not clear to me how should this behave in the case of a chain of nested phrase-logical-phrase operations.

I would expect that the "position" of a match should depend on whether it's the LHS or RHS of the phrase operator. If it's the LHS, I'd expect the "position" to be the "end" of the match. If it's the RHS, I'd expect the "position" to be the "beginning" of the match.

Maybe that's the wrong intuition and it's always the beginning of the match?

Jordan

pgsql-bugs by date:

Previous
From: Pavel Borisov
Date:
Subject: Re: BUG #17542: tsquery returns incorrect results with nested, conjuncted followed-by operators
Next
From: PG Bug reporting form
Date:
Subject: BUG #17545: Incorrect selectivity for IS NOT DISTINCT FROM and NULLs