Re: plan shape work

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Richard Guo <guofenglinux(at)gmail(dot)com>, Alexandra Wang <alexandra(dot)wang(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "bruce(at)momjian(dot)us" <bruce(at)momjian(dot)us>, lepihov(at)gmail(dot)com
Subject: Re: plan shape work
Date: 2025-10-09 12:34:56
Message-ID: CA+TgmoantobnAc_JHKYDkD+Yd3TNaZoSsNDz+F8KrBMRudp8Ww@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 8, 2025 at 11:04 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Грем Снорт 2025-10-09 12:37:25 [PATCH TEST] Fix logical replication setup in subscription test `t/009_matviews.pl`
Previous Message Kirill Reshke 2025-10-09 12:33:54 Re: Remove custom redundant full page write description from GIN