Re: BUG #5732: parsing of: "WHERE mycol=123AND ..."

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Josh Kupershmidt <schmiddy(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5732: parsing of: "WHERE mycol=123AND ..."
Date: 2010-10-29 00:20:19
Message-ID: 28903.1288311619@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Jeff Davis <pgsql(at)j-davis(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Josh Kupershmidt 2010-10-29 00:57:36 Re: BUG #5732: parsing of: "WHERE mycol=123AND ..."
Previous Message Jeff Davis 2010-10-29 00:03:22 Re: BUG #5732: parsing of: "WHERE mycol=123AND ..."