Re: Precedence of standard comparison operators - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Precedence of standard comparison operators
Date
Msg-id 16054.1424619402@sss.pgh.pa.us
Whole thread Raw
In response to Re: Precedence of standard comparison operators  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> Attached is a draft patch to bring the precedence of comparison operators
> and IS tests into line with the SQL standard.  I have not yet looked into
> producing warnings for changes in parsing decisions ...

I've made some progress on getting parse_expr.c to produce warnings by
after-the-fact analysis of the raw parse tree, and I think it can be made
to work.  However, I've run into two stumbling blocks that greatly limit
the quality of the warnings, and will need to be fixed as separate
patches:

1. BooleanTest and NullTest node types don't carry location pointers,
so there's no way to give an error cursor position referencing them.
Simple enough addition.  I think we left these out because there were
no post-grammar error reports involving them, but now we need some.

2. gram.y expands BETWEEN operations into complex AND/OR nests on sight,
losing the information that there was a BETWEEN there, which is important
if we're to detect possible precedence changes involving BETWEEN.

What we should do about #2 is preserve BETWEEN as a distinct construct
in the output of raw parsing.  This is a good thing anyway, because in
the long run we are going to want to fix BETWEEN's semantic issues
(such as multiple evaluation of possibly-volatile input expressions)
and fixing what the grammar does with it is an essential first step.

Barring objection I'll go do both of those things as separate patches,
and then come back to the precedence warnings.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Allow "snapshot too old" error, to prevent bloat
Next
From: Gavin Flower
Date:
Subject: Re: Abbreviated keys for Numeric