Re: Non-decimal integer literals

On 13.02.22 13:14, John Naylor wrote:
> On Wed, Jan 26, 2022 at 10:10 PM Peter Eisentraut
> <peter.eisentraut@enterprisedb.com> wrote:
>> [v8 patch]
> 
> 0001-0004 seem pretty straightforward.

These have been committed.

> 
> 0005:
> 
>   {realfail1} {
> - /*
> - * throw back the [Ee], and figure out whether what
> - * remains is an {integer} or {decimal}.
> - */
> - yyless(yyleng - 1);
>    SET_YYLLOC();
> - return process_integer_literal(yytext, yylval);
> + yyerror("trailing junk after numeric literal");
>    }
> 
> realfail1 has been subsumed by integer_junk and decimal_junk, so that
> pattern can be removed.

Committed with that change.

I found that the JSON path lexer has the same trailing-junk issue.  I 
have researched the relevant ECMA standard and it explicitly points out 
that this is not allowed.  I will look into that separately.  I'm just 
pointing that out here because grepping for "realfail1" will still show 
a hit after this.

The remaining patches are material for PG16 at this point, and I will 
set the commit fest item to returned with feedback in the meantime.

> 0006:
> 
> Minor nit -- the s/decimal/numeric/ change doesn't seem to have any
> notational advantage, but it's not worse, either.

I did that because with the addition of non-decimal literals, the word 
"decimal" becomes ambiguous or misleading.  (It doesn't mean "uses 
decimal digits" but "has a decimal point".)  (Of course, "numeric" isn't 
entirely free of ambiguity, but there are only so many words available 
in this space. ;-) )

> 0007:
> 
> I've attached an addendum to restore the no-backtrack property.

Thanks, that is helpful.

> Will the underscore syntax need treatment in the input routines as well?

Yeah, various additional work is required for this.