Re: Generate GUC tables from .dat file

From: "David E(dot) Wheeler" <david(at)justatheory(dot)com>
To: John Naylor <johncnaylorls(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se>
Subject: Re: Generate GUC tables from .dat file
Date: 2025-09-01 13:02:23
Message-ID: 48E7965C-DF18-4D8A-A660-AFEA2F78CAD9@justatheory.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi John,

On Sep 1, 2025, at 03:21, John Naylor <johncnaylorls(at)gmail(dot)com> wrote:

> I find the loop over @parse a lot less readable this way.

Yeah, that’s the trade-off. Probably not worth it to reduce legibility.

>> * Use the /r regex return sequence to simplify dquote() (requires Perl 5.14, IIRC)
>
> I think our perlcritic configuration would complain about the lack of
> return statement.

Oh, I ran the indenter but not perlcritic.

>> * Use {$fh} syntax to make file handle arguments clearer
>
> With this I wonder why the variable looks different for `print` vs. `open`.

I’ve never seen {} used with open. I just tried it, and Perl complained:

Use of uninitialized value $fh in anonymous hash ({}) at try line 8.

The use of {$fh} with print/say always looked like an exception to me, I’m not sure what the syntax resolves to, but it’s not a hash reference. At any rate, Perl best practices I’ve been aware of (admittedly 10y or so out of date) recommended it to distinguish the file handle from the values actually being printed.

Best,

David

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Rahila Syed 2025-09-01 13:05:55 Re: Improve LWLock tranche name visibility across backends
Previous Message Mihail Nikalayeu 2025-09-01 13:00:39 Re: Adding REPACK [concurrently]