Re: plan shape work

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(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 03:04:37
Message-ID: 2805458.1759979077@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> Does it make sense to explicitly initialize glob->subplanNames in
> standard_planner()? I understand this might seem pointless since
> makeNode() zeroes all fields by default, but subplanNames is currently
> the only field in PlannerGlobal that isn't explicitly initialized. I
> previously committed a patch (2c0ed86d3) to ensure all PlannerGlobal
> fields are explicitly initialized, and I'd prefer to maintain that
> consistency.

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.

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2025-10-09 03:04:44 Re: doc: Improve description of io_combine_limit and io_max_combine_limit GUCs
Previous Message suyu.cmj 2025-10-09 02:49:39 Re: Question about InvalidatePossiblyObsoleteSlot()