Re: refactoring - share str2*int64 functions

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: refactoring - share str2*int64 functions
Дата
Msg-id CA+hUKGK_pJ4iERx7Ve5Cor-qGSOf7iCYaSWMLZr_16=PBiFkpQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: refactoring - share str2*int64 functions  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Removing unneeded downlink field from nbtree stack struct
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)