Date: Mon, 14 Feb 2022 19:49:59 +0100
From: Christoph Berg <myon@debian.org>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Non-decimal integer literals
Message-ID: <YgqkV4HOuir1IemY@msg.df7cb.de>
Mail-Followup-To: Christoph Berg <myon@debian.org>,
	Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
References: <b239564c-cad0-b23e-c57e-166d883cb97d@enterprisedb.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b239564c-cad0-b23e-c57e-166d883cb97d@enterprisedb.com>
Archived-At: 
 <https://www.postgresql.org/message-id/YgqkV4HOuir1IemY%40msg.df7cb.de>
Precedence: bulk

Re: Peter Eisentraut
> This adds support in the lexer as well as in the integer type input
> functions.
> 
> Those core parts are straightforward enough, but there are a bunch of other
> places where integers are parsed, and one could consider in each case
> whether they should get the same treatment, for example the replication
> syntax lexer, or input function for oid, numeric, and int2vector.

One thing I always found weird is that timeline IDs appear most
prominently as hex numbers in WAL filenames, but they are printed as
decimal in the log ("new timeline id nn"), and have to be specified as
decimal in recovery_target_timeline.

Perhaps both these could make use of 0xhex numbers as well.

Christoph