Re: Precedence of standard comparison operators

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

In response to

Browse pgsql-hackers by date

  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