Re: Non-decimal integer literals

Rebased patch set

On 13.01.22 14:42, Peter Eisentraut wrote:
> Another modest update, because of the copyright year update preventing 
> the previous patches from applying cleanly.
> 
> I also did a bit of work on the ecpg scanner so that it also handles 
> some errors on par with the main scanner.
> 
> There is still no automated testing of this in ecpg, but I have a bunch 
> of single-line test files that can provoke various errors.  I will keep 
> these around and maybe put them into something more formal in the future.
> 
> 
> On 30.12.21 10:43, Peter Eisentraut wrote:
>> 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.
>>>
>>>