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