From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Non-decimal integer literals |
Date: | 2021-12-30 09:43:30 |
Message-ID: | 577603ec-787b-61b8-23a2-1bd0457ed1c7@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
There has been some other refactoring going on, which made this patch
set out of date. So here is an update.
The old pg_strtouint64() has been removed, so there is no longer a
naming concern with patch 0001. That one should be good to go.
I also found that yet another way to parse integers in pg_atoi() has
mostly faded away in utility, so I removed the last two callers and
removed the function in 0002 and 0003.
The remaining patches are as before, with some of the review comments
applied. I still need to write some lexing unit tests for ecpg, which I
haven't gotten to yet. This affects patches 0004 and 0005.
As mentioned before, patches 0006 and 0007 are more feature previews at
this point.
On 01.12.21 16:47, Peter Eisentraut wrote:
> On 25.11.21 18:51, John Naylor wrote:
>> If we're going to change the comment anyway, "the parser" sounds more
>> natural. Aside from that, 0001 and 0002 can probably be pushed now, if
>> you like.
>
> done
>
>> --- a/src/interfaces/ecpg/preproc/pgc.l
>> +++ b/src/interfaces/ecpg/preproc/pgc.l
>> @@ -365,6 +365,10 @@ real ({integer}|{decimal})[Ee][-+]?{digit}+
>> realfail1 ({integer}|{decimal})[Ee]
>> realfail2 ({integer}|{decimal})[Ee][-+]
>>
>> +integer_junk {integer}{ident_start}
>> +decimal_junk {decimal}{ident_start}
>> +real_junk {real}{ident_start}
>>
>> A comment might be good here to explain these are only in ECPG for
>> consistency with the other scanners. Not really important, though.
>
> Yeah, it's a bit weird that not all the symbols are used in ecpg. I'll
> look into explaining this better.
>
>> 0006
>>
>> +{hexfail} {
>> + yyerror("invalid hexadecimal integer");
>> + }
>> +{octfail} {
>> + yyerror("invalid octal integer");
>> }
>> -{decimal} {
>> +{binfail} {
>> + yyerror("invalid binary integer");
>> + }
>>
>> It seems these could use SET_YYLLOC(), since the error cursor doesn't
>> match other failure states:
>
> ok
>
>> We might consider some tests for ECPG since lack of coverage has been
>> a problem.
>
> right
>
>> Also, I'm curious: how does the spec work as far as deciding the year
>> of release, or feature-freezing of new items?
>
> The schedule has recently been extended again, so the current plan is
> for SQL:202x with x=3, with feature freeze in mid-2022.
>
> So the feature patches in this thread are in my mind now targeting
> PG15+1. But the preparation work (up to v5-0005, and some other number
> parsing refactoring that I'm seeing) could be considered for PG15.
>
> I'll move this to the next CF and come back with an updated patch set in
> a little while.
>
>
Attachment | Content-Type | Size |
---|---|---|
v6-0001-Move-scanint8-to-numutils.c.patch | text/plain | 10.8 KB |
v6-0002-Remove-one-use-of-pg_atoi.patch | text/plain | 780 bytes |
v6-0003-Remove-pg_atoi.patch | text/plain | 5.3 KB |
v6-0004-Add-test-case-for-trailing-junk-after-numeric-lit.patch | text/plain | 2.2 KB |
v6-0005-Reject-trailing-junk-after-numeric-literals.patch | text/plain | 5.4 KB |
v6-0006-Non-decimal-integer-literals.patch | text/plain | 28.4 KB |
v6-0007-WIP-Underscores-in-numeric-literals.patch | text/plain | 3.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Japin Li | 2021-12-30 10:44:23 | Re: Autovacuum and idle_session_timeout |
Previous Message | Guillaume Lelarge | 2021-12-30 09:18:37 | Autovacuum and idle_session_timeout |