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'
Чтобы сделать работу с сайтом удобнее, мы используем cookie и аналитический сервис «Яндекс.Метрика». Продолжая пользоваться сайтом, вы соглашаетесь с их использованием.