Re: BUG #5732: parsing of: "WHERE mycol=123AND ..." - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #5732: parsing of: "WHERE mycol=123AND ..."
Date
Msg-id 28903.1288311619@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #5732: parsing of: "WHERE mycol=123AND ..."  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: BUG #5732: parsing of: "WHERE mycol=123AND ..."  (Greg Stark <gsstark@mit.edu>)
List pgsql-bugs
Jeff Davis <pgsql@j-davis.com> writes:
> On Thu, 2010-10-28 at 23:46 +0000, Josh Kupershmidt wrote:
>> SELECT * FROM mytab WHERE mycol = 2OR true;

> Is that inconsistent with the standard?

I was just looking at that.  The spec lumps both <unsigned numeric
literal> and <keyword> under <nondelimiter token>, and says that there
must be a <separator> (ie, whitespace or comment) between adjacent
<nondelimiter token>s.  However, I would tend to read that as
instructing users how to write portable SQL, not as instructing
implementations that they must throw an error when they find two tokens
that aren't separated by whitespace.  The actual behavior of an
implementation in such a case could be regarded as a spec extension.

I experimented a bit with mysql's behavior, and it seems that (at least
in 5.1.51) what they do is treat "1and" or "2or" as if it were an
identifier.  They're definitely not throwing an error, at least not on
that token --- they will of course spit up later if the remainder of
the input is inconsistent with the assumption that that part is an
identifier.  I don't have any other SQL DBMSes handy to experiment with,
but I wouldn't be surprised to find multiple behaviors out there.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Jeff Davis
Date:
Subject: Re: BUG #5732: parsing of: "WHERE mycol=123AND ..."
Next
From: Josh Kupershmidt
Date:
Subject: Re: BUG #5732: parsing of: "WHERE mycol=123AND ..."