Re: gen_guc_tables.pl: Validate required GUC fields before code generation

Chao Li <li.evan.chao@gmail.com>

From: Chao Li <li.evan.chao@gmail.com>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-11-19T09:19:57Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. gen_guc_tables.pl: Validate required GUC fields before code generation

Attachments

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.
https://www.highgo.com/