Re: [HACKERS] Precedence of new phrase search tsquery operator

[Teodor Sigaev]

Attached patch changes a precedences of operations to |, &, <->, | in ascending
order. BTW, it simplifies a bit a code around printing and parsing of tsquery.


|, &, <->, ! of course
--
Teodor Sigaev   E-mail: teo...@sigaev.ru
   WWW: http://www.sigaev.ru/


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Precedence of new phrase search tsquery operator

[Teodor Sigaev]

On Wed, Jun 8, 2016 at 7:13 PM, Tom Lane  wrote:

It appears that the new <-> operator has been made to have exactly the
same grammatical precedence as the existing & (AND) operator.  Thus,
for example, 'a & b <-> c'::tsquery means something different from
'b <-> c & a'::tsquery:
I find this surprising.  My intuitive feeling is that <-> ought to
bind tighter than & (and therefore also tighter than |).  What's
the reasoning for making it act like this?


ah, now we remember :)   The idea about equivalence of  & and <->
operators appeared in situation when <-> degenerates to & in case of
absence of positional information. Looks like we mixed different
things, will fix.


Attached patch changes a precedences of operations to |, &, <->, | in ascending 
order. BTW, it simplifies a bit a code around printing and parsing of tsquery.


--
Teodor Sigaev   E-mail: teo...@sigaev.ru
   WWW: http://www.sigaev.ru/


phrase_predecence-2.patch
Description: binary/octet-stream

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Precedence of new phrase search tsquery operator

[Oleg Bartunov]

On Wed, Jun 8, 2016 at 7:13 PM, Tom Lane  wrote:
> It appears that the new <-> operator has been made to have exactly the
> same grammatical precedence as the existing & (AND) operator.  Thus,
> for example, 'a & b <-> c'::tsquery means something different from
> 'b <-> c & a'::tsquery:
>
> regression=# select 'a & b <-> c'::tsquery;
>   tsquery
> ---
>  ( 'a' <-> 'c' ) & ( 'b' <-> 'c' )
> (1 row)
>
> regression=# select 'b <-> c & a'::tsquery;
> tsquery
> ---
>  ( 'b' <-> 'c' ) & 'a'
> (1 row)
>
> I find this surprising.  My intuitive feeling is that <-> ought to
> bind tighter than & (and therefore also tighter than |).  What's
> the reasoning for making it act like this?

ah, now we remember :)   The idea about equivalence of  & and <->
operators appeared in situation when <-> degenerates to & in case of
absence of positional information. Looks like we mixed different
things, will fix.

>
> regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Precedence of new phrase search tsquery operator

[Oleg Bartunov]

On Wed, Jun 8, 2016 at 7:13 PM, Tom Lane  wrote:
> It appears that the new <-> operator has been made to have exactly the
> same grammatical precedence as the existing & (AND) operator.  Thus,
> for example, 'a & b <-> c'::tsquery means something different from
> 'b <-> c & a'::tsquery:
>
> regression=# select 'a & b <-> c'::tsquery;
>   tsquery
> ---
>  ( 'a' <-> 'c' ) & ( 'b' <-> 'c' )
> (1 row)
>
> regression=# select 'b <-> c & a'::tsquery;
> tsquery
> ---
>  ( 'b' <-> 'c' ) & 'a'
> (1 row)
>
> I find this surprising.  My intuitive feeling is that <-> ought to
> bind tighter than & (and therefore also tighter than |).  What's
> the reasoning for making it act like this?

I don't remember, but it looks like a bug. I found another issue with that

If some dictionary returns two infinitives, like:

select * from to_tsquery('en','leavings');
  to_tsquery
--
 'leavings' | 'leave'
(1 row)


then following query looks like a bug

select to_tsquery('en', 'aa & leavings <-> tut');
to_tsquery
---
 ( 'aa' <-> 'tut' ) & ( 'leavings' <-> 'tut' | 'leave' <-> 'tut' )
(1 row)

It should be definitely

select to_tsquery('en', 'aa & leavings <-> tut');
to_tsquery
---
  'aa'  & ( 'leavings' <-> 'tut' | 'leave' <-> 'tut' )
(1 row)

so, yes, <-> should be more tight than &.

>
> regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Precedence of new phrase search tsquery operator

[Tom Lane]

It appears that the new <-> operator has been made to have exactly the
same grammatical precedence as the existing & (AND) operator.  Thus,
for example, 'a & b <-> c'::tsquery means something different from
'b <-> c & a'::tsquery:

regression=# select 'a & b <-> c'::tsquery;
  tsquery  
---
 ( 'a' <-> 'c' ) & ( 'b' <-> 'c' )
(1 row)

regression=# select 'b <-> c & a'::tsquery;
tsquery
---
 ( 'b' <-> 'c' ) & 'a'
(1 row)

I find this surprising.  My intuitive feeling is that <-> ought to
bind tighter than & (and therefore also tighter than |).  What's
the reasoning for making it act like this?

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers