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
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 |