Precedence of new phrase search tsquery operator
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
On Wed, Jun 8, 2016 at 7:13 PM, Tom Lane <tgl@sss.pgh.pa.us> 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
On Wed, Jun 8, 2016 at 7:13 PM, Tom Lane <tgl@sss.pgh.pa.us> 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
On Wed, Jun 8, 2016 at 7:13 PM, Tom Lane <tgl@sss.pgh.pa.us> 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: teodor@sigaev.ru
WWW: http://www.sigaev.ru/
Attachments:
phrase_predecence-2.patchbinary/octet-stream; name=phrase_predecence-2.patchDownload+121-116
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: teodor@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