| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, vignesh C <vignesh21(at)gmail(dot)com> |
| Subject: | Re: making relfilenodes 56 bits |
| Date: | 2022-07-29 18:12:53 |
| Message-ID: | 20220729181253.jg6mjfoezznzgfor@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2022-07-29 18:23:47 | Re: Oversight in slab.c SlabContextCreate(), initial memory allocation size is not populated to context->mem_allocated |
| Previous Message | Tom Lane | 2022-07-29 17:55:10 | Re: Oversight in slab.c SlabContextCreate(), initial memory allocation size is not populated to context->mem_allocated |