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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-bugs by date

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