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

From Fabien COELHO
Subject Re: refactoring - share str2*int64 functions
Date
Msg-id alpine.DEB.2.21.1907160725020.8986@lancre
Whole thread Raw
In response to Re: refactoring - share str2*int64 functions  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: refactoring - share str2*int64 functions  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hello Thomas,

> 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().

I added the pg_ prefix as a poor man's namespace because the function can 
be used by external tools (eg contribs), so as to avoid potential name 
conflicts.

I agree that such conflicts are less probable if the name does not replace 
something existing.

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

It can be removed, or not. So you do as you feel.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: refactoring - share str2*int64 functions
Next
From: Rajkumar Raghuwanshi
Date:
Subject: getting ERROR "relation 16401 has no triggers" with partition foreignkey alter