Re: making relfilenodes 56 bits - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: making relfilenodes 56 bits
Date
Msg-id CAFiTN-srGSye68DGvkT25DavmQEeTRXJSbJH86WYiqDY3QjPUg@mail.gmail.com
Whole thread Raw
In response to Re: making relfilenodes 56 bits  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: making relfilenodes 56 bits
List pgsql-hackers
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().

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

Attachment

pgsql-hackers by date:

Previous
From: Roberto C. Sánchez
Date:
Subject: Re: Request for assistance to backport CVE-2022-1552 fixes to 9.6 and 9.4
Next
From: Robert Haas
Date:
Subject: Re: generic plans and "initial" pruning