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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #5732: parsing of: "WHERE mycol=123AND ..."
Дата
Msg-id 28903.1288311619@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #5732: parsing of: "WHERE mycol=123AND ..."  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: BUG #5732: parsing of: "WHERE mycol=123AND ..."
Список 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 по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: BUG #5732: parsing of: "WHERE mycol=123AND ..."
Следующее
От: Josh Kupershmidt
Дата:
Сообщение: Re: BUG #5732: parsing of: "WHERE mycol=123AND ..."