On 12/29/20 10:18 AM, Peter Eisentraut wrote:
> On 2020-12-28 21:54, Tom Lane wrote:
>> Peter Eisentraut <peter.eisentraut@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
