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

From Robert Haas
Subject Re: making relfilenodes 56 bits
Date
Msg-id CA+TgmobZmhx8F1ajnb1A0pBe=u3+LCHN48BMZ968fcDjiiLMtQ@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
Re: making relfilenodes 56 bits
Re: making relfilenodes 56 bits
List pgsql-hackers
On Thu, Jul 28, 2022 at 10:29 AM Robert Haas <robertmhaas@gmail.com> wrote:
> > I have done some cleanup in 0002 as well, basically, earlier we were
> > storing the result of the BufTagGetRelFileLocator() in a separate
> > variable which is not required everywhere.  So wherever possible I
> > have avoided using the intermediate variable.
>
> I'll have a look at this next.

I was taught that when programming in C one should avoid returning a
struct type, as BufTagGetRelFileLocator does. I would have expected it
to return void and take an argument of type RelFileLocator * into
which it writes the results. On the other hand, I was also taught that
one should avoid passing a struct type as an argument, and smgropen()
has been doing that since Tom Lane committed
87bd95638552b8fc1f5f787ce5b862bb6fc2eb80 all the way back in 2004. So
maybe this isn't that relevant any more on modern compilers? Or maybe
for small structs it doesn't matter much? I dunno.

Other than that, I think your 0002 looks fine.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Michail Nikolaev
Date:
Subject: Re: Slow standby snapshot
Next
From: Nathan Bossart
Date:
Subject: Re: Oversight in slab.c SlabContextCreate(), initial memory allocation size is not populated to context->mem_allocated