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
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] |