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.
>
>