Re: Cleaning up perl code

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Alexander Lakhin <exclusion(at)gmail(dot)com>
Cc: Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Cleaning up perl code
Date: 2024-07-02 01:11:46
Message-ID: ZoNT0uP6lYc5Lg1A@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 24, 2024 at 02:09:49PM +0900, Michael Paquier wrote:
> For now, I have staged for commit the attached, that handles most of
> the changes from Alexander (msvc could go for more cleanup?).

This one has been applied as of 0c1aca461481 now that v18 is
open.

> I'll look at the changes from Dagfinn after that, including if perlcritic
> could be changed. I'll handle the first part when v18 opens up, as
> that's cosmetic.

I'm still biased about the second set of changes proposed here,
though. ProhibitUnusedVariables would have benefits when writing perl
code in terms of clarity because we would avoid useless stuff, but it
seems to me that we should put more efforts into the unification of
the errcodes parsing paths first to have a cleaner long-term picture.

That's not directly the fault of this proposal that we have the same
parsing rules spread across three PL languages, so perhaps what's
proposed is fine as-is, at the end.

Any thoughts or comments from others more familiar with
ProhibitUnusedVariables?
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-07-02 01:18:59 Re: ALTER TABLE SET ACCESS METHOD on partitioned tables
Previous Message Andy Fan 2024-07-02 01:07:23 Re: Make tuple deformation faster