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

From Alvaro Herrera
Subject Re: making relfilenodes 56 bits
Date
Msg-id 20220729181253.jg6mjfoezznzgfor@alvherre.pgsql
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 2022-Jul-29, Robert Haas wrote:

> I was taught that when programming in C one should avoid returning a
> struct type, as BufTagGetRelFileLocator does.

Doing it like that helps RelFileLocatorSkippingWAL, which takes a bare
RelFileLocator as argument.  With this coding you can call one function
with the other function as its argument.

However, with the current definition of relpathbackend() and siblings,
it looks quite disastrous -- BufTagGetRelFileLocator is being called
three times.  You could argue that a solution would be to turn those
macros into static inline functions.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"I'm impressed how quickly you are fixing this obscure issue. I came from 
MS SQL and it would be hard for me to put into words how much of a better job
you all are doing on [PostgreSQL]."
 Steve Midgley, http://archives.postgresql.org/pgsql-sql/2008-08/msg00000.php



pgsql-hackers by date:

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