Re: GUC tables - use designated initializers

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Smith <smithpb2250(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: GUC tables - use designated initializers
Date: 2022-09-27 16:21:01
Message-ID: 3800142.1664295661@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Smith <smithpb2250(at)gmail(dot)com> writes:
> Enums index a number of the GUC tables. This all relies on the
> elements being carefully arranged to be in the same order as those
> enums. There are comments to say what enum index belongs to each table
> element.
> But why not use designated initializers to enforce what the comments
> are hoping for?

Interesting proposal, but it's not clear to me that this solution makes
the code more bulletproof rather than less so. Yeah, you removed the
order dependency, but the other concern here is that the array gets
updated at all when adding a new enum entry. This method seems like
it'd help disguise such an oversight. In particular, the adjacent
StaticAssertDecls about the array lengths are testing something different
than they used to, and I fear they lost some of their power. Can we
improve those checks so they'd catch a missing entry again?

> Furthermore, with this change, now the GUC table elements are able to
> be rearranged into any different order - eg alphabetical - if that
> would be useful (my patch does not do this).

If anything, that's an anti-feature IMV. I quite dislike code where
the same set of items are dealt with in randomly different orders
in different places.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Morris 2022-09-27 16:22:39 Re: Temporary file access API
Previous Message Nazir Bilal Yavuz 2022-09-27 15:35:45 Re: kerberos/001_auth test fails on arm CPU darwin