Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c) - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)
Date
Msg-id CAEudQAoGk4onWzxaUR86hQ79AokV7p+MZixK650bn+91gYAkEg@mail.gmail.com
Whole thread Raw
In response to Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)
List pgsql-hackers
Em qua., 24 de ago. de 2022 às 16:00, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> On 24.08.22 16:30, Alvaro Herrera wrote:
>> If you do this, you're creating a potential backpatching hazard.  This
>> is OK if we get something in return, so a question to ask is whether
>> there is any benefit in doing it.

> I don't follow how this is a backpatching hazard.

Call me a trogdolyte, but I don't follow how it's an improvement.
It looks to me like an entirely random change that doesn't get rid
of assumptions about what the bits are, it just replaces one set of
assumptions with a different set.  Moreover, the new set of assumptions
may include "there are no padding bits in here", which is mighty fragile
and hard to verify.  So I frankly do not find this a stylistic improvement.
But, these same arguments apply to Designated Initializers [1].

like:
struct foo a = {
   .i = 0,
   .b = 0,
};

That is slowly being introduced and IMHO brings the same problems with padding bits.

regards,
Ranier Vilela

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)
Next
From: Robert Haas
Date:
Subject: Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)