Hi,
On 2018-08-30 13:54:41 -0300, Alvaro Herrera wrote:
> On 2018-Aug-30, Mark Dilger wrote:
>
> > static struct config_bool ConfigureNamesBool[] =
> > {
> > {
> > {"enable_seqscan", PGC_USERSET, QUERY_TUNING_METHOD,
> > gettext_noop("Enables the planner's use of sequential-scan
> > plans."),
> > NULL
> > },
> > &enable_seqscan,
> > true,
> > NULL, NULL, NULL
> > },
>
> Personally, I dislike this form -- it's very opaque and I have to refer
> to the struct definition each time I want to add a new member, to make
> sure I'm assigning the right thing.
Dito. Especially because it looks different for the different types of
GUCs.
> I welcome designated initializers in this case even though it becomes
> more verbose. I don't think explicitly initializing to NULLs is
> sensible in this case; let's just omit those fields.
Yea - I mean a large portion of them previously weren't initialized
either, so there's really not a good reason to change that now.
> > What should the general rule be for initializing arrays of structs such as
> > these?
>
> I don't know what a general rule would be. Maybe we can try hand-
> inspecting a few cases, and come up with a general rule once we acquire
> sufficient experience.
I think we should have as rules:
1) Members should be defined in the same order as in the struct, that's
the requirement C++ standard is going to impose. Think it's also
reasonable stylistically.
2) It's OK to omit setting members if zero-initialization obviously is
correct.
We probably should also check how well pgindent copes, and whether that
dictates some formatting choices.
Greetings,
Andres Freund
