Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Kupershmidt <schmiddy(at)gmail(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5732: parsing of: "WHERE mycol=123AND ..."
Date: 2010-10-29 01:52:25
Message-ID: 15290.1288317145@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Josh Kupershmidt <schmiddy(at)gmail(dot)com> writes:
> The only mild concern I have is if this could possibly lead to
> ambiguous parsing in some situations, though I've played with some
> examples and I haven't seen any yet. It would be nice to have this
> behavior documented somewhere though.

The fine manual currently says (at the head of section 4.1):

A token can be a key word, an identifier, a quoted identifier, a literal
(or constant), or a special character symbol. Tokens are normally
separated by whitespace (space, tab, newline), but need not be if there
is no ambiguity (which is generally only the case if a special character
is adjacent to some other token type).

The parenthetical remark at the end fails to point out the special case
of number-followed-by-identifier-that-doesn't-look-like-an-exponent.
But I'm not sure that it's reasonable to try to shoehorn in a mention
of the case.  Might be a good idea to change "generally" to "usually",
though, since "generally" might be read as implying that that's the
exact and only rule.

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: Josh BerkusDate: 2010-10-29 05:33:11
Subject: What happened to SSL_CIPHERS?
Previous:From: Josh KupershmidtDate: 2010-10-29 01:29:17
Subject: Re: BUG #5732: parsing of: "WHERE mycol=123AND ..."

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group