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
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 Berkus||Date: 2010-10-29 05:33:11|
|Subject: What happened to SSL_CIPHERS?|
|Previous:||From: Josh Kupershmidt||Date: 2010-10-29 01:29:17|
|Subject: Re: BUG #5732: parsing of: "WHERE mycol=123AND ..."|