Re: Precedence of standard comparison operators

On 10 August 2015 at 16:31, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> >> On Sun, Aug 09, 2015 at 08:06:11PM -0400, Tom Lane wrote:
> >>> So yeah, I do think that getting a syntax error if you don't use
> >>> parentheses is the preferable behavior here.
>
> > If we raise a syntax error, then there should be very informative
> message,
>
> Yeah, it would sure be nice to throw something better than "syntax error".
> But I've looked at bison's facilities for that, and they're pretty bad.
> I'm not sure there's much we can do short of moving to some other parser
> generator tool, which would be a Large Undertaking ... and I don't know
> of any arguably-better tool anyway.
>

I would say that anyone who's tricksy enough to be using boolean logic in
the way you describe would be expected to have enough nouse about them to
either a) know what the precedences are or b) know that their lack of
knowledge means they should sprinkle their code with
​brackets
.​

Returning a syntax error for something that isn't actually an error in
syntax is a poor showing.
Are we to start
​expecting
syntax errors when people use comparison operators on
​NULLable​

​​
columns
​
without a COALESCE
​
because the comparison might do something they don't expect
​ if they haven't tested their code with NULL values
?

IMO using a = b < c as described is unnecessarily* horrid, *whichever* way
you mean it, and will only produce the sort of unreadability that generates
errors in the long run anyway (even if you understand it, chances are the
next poor sap reading your code won't) and deserves code that breaks,
especially if you're the sort of person who uses it without fully
understanding it.

(*Unnecessarily because there are clearer constructs - CASE springs to mind
- that do the same thing without the associated unreadability and/or
ambiguity)

Geoff