Re: Non-decimal integer literals

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