From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Precedence of standard comparison operators |
Date: | 2015-08-09 21:35:46 |
Message-ID: | 18810.1439156146@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Noah Misch <noah(at)leadboat(dot)com> writes:
>> Why in particular the following three precedence groups instead of
>> combining them as in SQL or subdividing further as in PostgreSQL 9.4?
> +%nonassoc '<' '>' '=' LESS_EQUALS GREATER_EQUALS NOT_EQUALS
> +%nonassoc BETWEEN IN_P LIKE ILIKE SIMILAR NOT_LA
> %nonassoc OVERLAPS
> OVERLAPS is a special case in that it doesn't really need precedence at
> all: both its arguments are required to be parenthesized. We could
> possibly have removed it from the precedence hierarchy altogether, but
> I didn't bother experimenting with that, just left it alone. But
> because of that, "moving BETWEEN/IN below it" doesn't really change
> anything.
I got off my rear and did the experiment, and found that indeed simply
removing "%nonassoc OVERLAPS" seems to work and not change any behavior
(in fact, the generated gram.c is identical). Shall we do that and remove
the listing of OVERLAPS in the documentation's precedence table?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2015-08-09 21:56:27 | WIP: Rework access method interface |
Previous Message | Stephen Frost | 2015-08-09 21:05:57 | Re: WIP: SCRAM authentication |