On 10 August 2015 at 16:31, Tom Lane <t...@sss.pgh.pa.us> wrote: > Pavel Stehule <pavel.steh...@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) Geoff
