On 12/29/20 10:18 AM, Peter Eisentraut wrote: > On 2020-12-28 21:54, Tom Lane wrote: >> Peter Eisentraut <peter.eisentr...@enterprisedb.com> writes: >>> I was surprised to find that this doesn't error: >>> => select 100a; >>> a >>> ----- >>> 100 >> >>> I suspect this and similar cases used to error before aliases without AS >>> were introduced. But now this seems possibly problematic. Should we >>> try to handle this better? >> >> Meh. I think you'd get more brickbats than kudos if you start insisting >> on a space there. >> >> I'm too lazy to try to decipher the SQL spec right now, but ISTR that >> it insists on whitespace between a numeric literal and an identifier. > > Yeah, non-delimiter tokens are supposed to be separated by delimiter > tokens. > >> So strictly speaking this SQL code is nonstandard anyway. But our >> lexer has always been forgiving about not requiring space if it's >> not logically necessary to separate tokens. I doubt trying to >> change that would improve matters. > > Well, the idea is to diagnose potential typos better. But if there is > no interest, then that's fine.
I am in favor of such a change so that we can also accept 1_000_000 which currently parses as "1 AS _000_000" (which also isn't compliant because identifiers cannot start with an underscore, but I don't want to take it that far). It would also allow us to have 0xdead_beef, 0o_777, and 0b1010_0000_1110 without most of it being interpreted as an alias. -- Vik Fearing
