Re: plan shape work
От | Robert Haas |
---|---|
Тема | Re: plan shape work |
Дата | |
Msg-id | CA+TgmoantobnAc_JHKYDkD+Yd3TNaZoSsNDz+F8KrBMRudp8Ww@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: plan shape work (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: