From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Non-decimal integer literals |
Date: | 2022-02-16 10:11:05 |
Message-ID: | bc462aff-675b-86e2-46e3-7eaf5ce3e75f@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 13.02.22 13:14, John Naylor wrote:
> On Wed, Jan 26, 2022 at 10:10 PM Peter Eisentraut
> <peter(dot)eisentraut(at)enterprisedb(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2022-02-16 10:47:31 | Re: initdb / bootstrap design |
Previous Message | Amit Kapila | 2022-02-16 10:05:34 | Re: Column Filtering in Logical Replication |