On Wed, Nov 19, 2025 at 4:33 PM Peter Eisentraut <[email protected]> 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/
v3-0001-gen_guc_tables.pl-Validate-required-GUC-fields-be.patch
Description: Binary data
