On Wed, Oct 8, 2025 at 11:04 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> We don't really have consensus on that point, I fear. I like the
> initialize-em-all-explicitly approach, but some other senior hackers
> think it's useless verbiage.
I'm in the "useless verbiage" camp.
> My argument for doing it explicitly is that when adding a new field
> to a struct, one frequently searches for existing references to a
> nearby field. Without initialize-em-all, this risks missing places
> where you need to initialize your new field. If you'd only set it
> to zero, then fine ... but what if that particular place needs some
> other initial value? So I think omitting initializations-to-zero
> risks future bugs of omission. Some other folk don't find that
> argument very compelling, though.
This problem does not typically happen for me because it is my habit
to start by grepping for makeNode(Whatever) -- or for relevant palloc
calls, for non-Node types -- at the very start of my research into any
topic, and only later to look into specific fields.
There might be a consistency argument for doing this in this case, if
other nearby fields are doing the same thing, and if one of you wants
to go and make it so I have much better things to do than spend time
complaining about it. But any code I write is likely to rely on
makeNode() or palloc0() to zero fields wherever relying on such a
thing is convenient, unless somebody forces me to do otherwise in a
particular case.
--
Robert Haas
EDB: http://www.enterprisedb.com
