Re: refactoring - share str2*int64 functions - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: refactoring - share str2*int64 functions
Date
Msg-id CA+hUKGK_pJ4iERx7Ve5Cor-qGSOf7iCYaSWMLZr_16=PBiFkpQ@mail.gmail.com
Whole thread Raw
In response to Re: refactoring - share str2*int64 functions  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: refactoring - share str2*int64 functions  (Michael Paquier <michael@paquier.xyz>)
Re: refactoring - share str2*int64 functions  (Fabien COELHO <coelho@cri.ensmp.fr>)
Re: refactoring - share str2*int64 functions  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Mon, Jul 15, 2019 at 5:08 PM Fabien COELHO <coelho@cri.ensmp.fr> wrote:
> The compromise I can offer is to change the name of the first one, say to
> "pg_scanint8" to reflect its former backend name. Attached a v4 which does
> a renaming so as to avoid the name similarity but signature difference. I
> also made both error messages identical.

Cool.  I'm not exactly sure when we should include 'pg_' in identifier
names.  It seems to be used for functions/macros that wrap or replace
something else with a similar name, like pg_pwrite(),
pg_attribute_noreturn(), ...  In this case it's just our own code that
we're moving, so I'm wondering if we should just call it scanint8().

If you agree, I think this is ready to commit.

-- 
Thomas Munro
https://enterprisedb.com



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Removing unneeded downlink field from nbtree stack struct
Next
From: Alvaro Herrera
Date:
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)