Re: Non-decimal integer literals - Mailing list pgsql-hackers

From Zhihong Yu
Subject Re: Non-decimal integer literals
Date
Msg-id CALNJ-vTmD7DGr9VU1x-Rt9GVJowQeX9t44CDhZJE=EUnp+7FeQ@mail.gmail.com
Whole thread Raw
In response to Re: Non-decimal integer literals  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: Non-decimal integer literals
Re: Non-decimal integer literals
List pgsql-hackers


On Thu, Nov 25, 2021 at 5:18 AM Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote:
On 01.11.21 07:09, Peter Eisentraut wrote:
> Here is an updated patch for this.  It's the previous patch polished a
> bit more, and it contains changes so that numeric literals reject
> trailing identifier parts without whitespace in between, as discussed.
> Maybe I should split that into incremental patches, but for now I only
> have the one.  I don't have a patch for the underscores in numeric
> literals yet.  It's in progress, but not ready.

Here is a progressed version of this work, split into more incremental
patches.  The first three patches are harmless code cleanups.  Patch 3
has an interesting naming conflict, noted in the commit message; ideas
welcome.  Patches 4 and 5 handle the rejection of trailing junk after
numeric literals, as discussed.  I have expanded that compared to the v4
patch to also cover non-integer literals.  It also comes with more tests
now.  Patch 6 is the titular introduction of non-decimal integer
literals, unchanged from before.
Hi,
For patch 3,

+int64
+pg_strtoint64(const char *s) 

How about naming the above function pg_scanint64()?
pg_strtoint64xx() can be named pg_strtoint64() - this would align with existing function:

pg_strtouint64(const char *str, char **endptr, int base)

Cheers

pgsql-hackers by date:

Previous
From: Marcos Pegoraro
Date:
Subject: Re: pg_upgrade and publication/subscription problem
Next
From: Andrew Dunstan
Date:
Subject: Re: Reduce function call costs on ELF platforms