Message-ID: <0f37d2ec-6689-4d23-7ba5-4d2a73c2666f@enterprisedb.com>
Date: Wed, 1 Dec 2021 16:47:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.3.2
Subject: Re: Non-decimal integer literals
Content-Language: en-US
To: John Naylor <john.naylor@enterprisedb.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
References: <b239564c-cad0-b23e-c57e-166d883cb97d@enterprisedb.com>
 <abb04ce4-a6b8-1c95-fa16-dc87e851e106@postgresfriends.org>
 <3260805.1631106874@sss.pgh.pa.us>
 <8f2cdc30-350a-9782-8d95-6865a4ccb857@postgresfriends.org>
 <31bba70a-f5a8-9276-37a6-fa6f2c4eee6c@enterprisedb.com>
 <0d895aa8-d1de-3637-9ad4-de0269918e77@enterprisedb.com>
 <b9d1f3e4-161c-f00c-c259-8391a2a91bd1@enterprisedb.com>
 <CALNJ-vTmD7DGr9VU1x-Rt9GVJowQeX9t44CDhZJE=EUnp+7FeQ@mail.gmail.com>
 <CAFBsxsEt_CFGk1vBEn=arrDKMFfdryjDHnNvFzpkhh+MktGNKA@mail.gmail.com>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
In-Reply-To: 
 <CAFBsxsEt_CFGk1vBEn=arrDKMFfdryjDHnNvFzpkhh+MktGNKA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/0f37d2ec-6689-4d23-7ba5-4d2a73c2666f%40enterprisedb.com>
Precedence: bulk

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.