Re: trailing junk in numeric literals

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