pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: John Naylor <john.naylor@enterprisedb.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Non-decimal integer literals
Date: Wed, 16 Feb 2022 11:11:05 +0100
Message-ID: <bc462aff-675b-86e2-46e3-7eaf5ce3e75f@enterprisedb.com> (raw)
In-Reply-To: <CAFBsxsGcgqJ_KO-1=jCUJKK2z5rCh2qsf7=VgNWzTvakLMDyBQ@mail.gmail.com>
References: <b239564c-cad0-b23e-c57e-166d883cb97d@enterprisedb.com>
	<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>
	<0f37d2ec-6689-4d23-7ba5-4d2a73c2666f@enterprisedb.com>
	<577603ec-787b-61b8-23a2-1bd0457ed1c7@enterprisedb.com>
	<be7fb835-abf9-2f5a-de5d-ad946a7d42e1@enterprisedb.com>
	<c42cb38a-ac42-dd92-2935-dce3b9806e26@enterprisedb.com>
	<CA+TgmoZv2Q11P1JbF+ziu1b8vsBpcjfPqXsHMR0hJqSTeLP1xQ@mail.gmail.com>
	<bef9c869-e773-f792-fde2-d7555add2879@enterprisedb.com>
	<CA+TgmoZRJzBe6yKeBpQ2auHndeV-bzygSY=gr0A0KixZ2giKNg@mail.gmail.com>
	<2317133.1643155358@sss.pgh.pa.us>
	<97aa22d7-b80f-efa1-f368-3dbf73a15980@enterprisedb.com>
	<CAFBsxsGcgqJ_KO-1=jCUJKK2z5rCh2qsf7=VgNWzTvakLMDyBQ@mail.gmail.com>


On 13.02.22 13:14, John Naylor wrote:
> On Wed, Jan 26, 2022 at 10:10 PM Peter Eisentraut
> <peter.eisentraut@enterprisedb.com> wrote:
>> [v8 patch]
> 
> 0001-0004 seem pretty straightforward.

These have been committed.

> 
> 0005:
> 
>   {realfail1} {
> - /*
> - * throw back the [Ee], and figure out whether what
> - * remains is an {integer} or {decimal}.
> - */
> - yyless(yyleng - 1);
>    SET_YYLLOC();
> - return process_integer_literal(yytext, yylval);
> + yyerror("trailing junk after numeric literal");
>    }
> 
> realfail1 has been subsumed by integer_junk and decimal_junk, so that
> pattern can be removed.

Committed with that change.

I found that the JSON path lexer has the same trailing-junk issue.  I 
have researched the relevant ECMA standard and it explicitly points out 
that this is not allowed.  I will look into that separately.  I'm just 
pointing that out here because grepping for "realfail1" will still show 
a hit after this.

The remaining patches are material for PG16 at this point, and I will 
set the commit fest item to returned with feedback in the meantime.

> 0006:
> 
> Minor nit -- the s/decimal/numeric/ change doesn't seem to have any
> notational advantage, but it's not worse, either.

I did that because with the addition of non-decimal literals, the word 
"decimal" becomes ambiguous or misleading.  (It doesn't mean "uses 
decimal digits" but "has a decimal point".)  (Of course, "numeric" isn't 
entirely free of ambiguity, but there are only so many words available 
in this space. ;-) )

> 0007:
> 
> I've attached an addendum to restore the no-backtrack property.

Thanks, that is helpful.

> Will the underscore syntax need treatment in the input routines as well?

Yeah, various additional work is required for this.





view thread (62+ messages)  latest in thread

Message-ID: <bc462aff-675b-86e2-46e3-7eaf5ce3e75f@enterprisedb.com>
Permalink:  ../bc462aff-675b-86e2-46e3-7eaf5ce3e75f@enterprisedb.com/
Also on:    postgresql.org/message-id/bc462aff-675b-86e2-46e3-7eaf5ce3e75f@enterprisedb.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: peter.eisentraut@enterprisedb.com, john.naylor@enterprisedb.com, tgl@sss.pgh.pa.us, robertmhaas@gmail.com
  Subject: Re: Non-decimal integer literals
  In-Reply-To: <bc462aff-675b-86e2-46e3-7eaf5ce3e75f@enterprisedb.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox