Re: gen_guc_tables.pl: Validate required GUC fields before code generation - Mailing list pgsql-hackers

From Chao Li
Subject Re: gen_guc_tables.pl: Validate required GUC fields before code generation
Date
Msg-id CAEoWx2nVsGwrSYstHt64fpCzE6m7PJaP+WK45eTJuzWwHuOTdw@mail.gmail.com
Whole thread Raw
In response to Re: gen_guc_tables.pl: Validate required GUC fields before code generation  (Peter Eisentraut <peter@eisentraut.org>)
List pgsql-hackers

On Wed, Nov 19, 2025 at 4:33 PM Peter Eisentraut <peter@eisentraut.org> wrote:
I find the data structures that you have constructed here barely
understandable:

     my %required_by_type = (
         int  => [qw(min max)],
         real => [qw(min max)],
         enum => [qw(options)],
     );

     for my $f (@required_common, @{ $required_by_type{$entry->{type} //
''} // [] }) {

[qw(min max)] is an array inside an array reference?  I think?  Do we
need two levels of nesting?

I think this // notation is unnecessarily confusing, and why do we need
two of them.  I thought your first patch

+        bool => [],   # no extra required fields
+        string => [], # no extra required fields

was clearer.  And that way, we also check that the field type is one of
the ones we support.

Yeah, the two levels of nesting is not necessary. It was to address the review comments of v1, I removed bool and string from required_by_type and combined the two loops into one. Because bool and string don't exist in required_by_type, so that $required_by_type{$entry->{type} needs a fallback, why's why // was added.

v3 goes back to v1 plus I add a check for unknown field type per your suggestion, for example:
```
error: guc_parameters.data line 2271: unknown GUC type 'intt'
```

Best regards,
Chao Li (Evan)
---------------------
HighGo Software Co., Ltd.
Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: PRI?64 vs Visual Studio (2022)
Next
From: Peter Eisentraut
Date:
Subject: Re: PRI?64 vs Visual Studio (2022)