Pavel Stehule <pavel.stehule@gmail.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)
