Re: making relfilenodes 56 bits

Поиск
Список
Период
Сортировка
От Dilip Kumar
Тема Re: making relfilenodes 56 bits
Дата
Msg-id CAFiTN-uJqaNa6Ss2ymg-=e39WXSZkZWPDjDw8Rsqr3_btoY4bg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: making relfilenodes 56 bits  (Dilip Kumar <dilipbalaut@gmail.com>)
Ответы Re: making relfilenodes 56 bits  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Wed, 27 Jul 2022 at 9:49 PM, Dilip Kumar <dilipbalaut@gmail.com> wrote:
On Wed, Jul 27, 2022 at 12:07 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Tue, Jul 26, 2022 at 2:07 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> > I have thought about it while doing so but I am not sure whether it is
> > a good idea or not, because before my change these all were macros
> > with 2 naming conventions so I just changed to inline function so why
> > to change the name.
>
> Well, the reason to change the name would be for consistency. It feels
> weird to have some NAMES_LIKETHIS() and other NamesLikeThis().
>
> Now, an argument against that is that it will make back-patching more
> annoying, if any code using these functions/macros is touched. But
> since the calling sequence is changing anyway (you now have to pass a
> pointer rather than the object itself) that argument doesn't really
> carry any weight. So I would favor ClearBufferTag(), InitBufferTag(),
> etc.

Okay, so I have renamed these 2 functions and BUFFERTAGS_EQUAL as well
to BufferTagEqual().

Just realised that this should have been BufferTagsEqual instead of BufferTagEqual

I will modify this and send an updated patch tomorrow.

Dilip
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: generic plans and "initial" pruning
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Reducing planning time on tables with many indexes