From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
cc: Noah Misch <noah@leadboat.com>, Alvaro Herrera <alvherre@2ndquadrant.com>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: cleaning perl code
In-reply-to: <ee6dff48-485d-974d-cc68-67ee86fe73b8@2ndQuadrant.com>
References: <20200414204432.GA22922@alvherre.pgsql>
 <86b0e20d-efc1-4169-aeb1-be49b3a375ab@2ndQuadrant.com>
 <20200416030101.GB977691@rfd.leadboat.com>
 <ee6dff48-485d-974d-cc68-67ee86fe73b8@2ndQuadrant.com>
Comments: In-reply-to Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
	message dated "Thu, 16 Apr 2020 08:50:35 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4425.1587045226.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 16 Apr 2020 09:53:46 -0400
Message-ID: <4426.1587045226@sss.pgh.pa.us>
Precedence: bulk

Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 4/15/20 11:01 PM, Noah Misch wrote:
>> It would be an unpleasant surprise to cause a perlcritic buildfarm fail=
ure by
>> moving a function, verbatim, from a non-strategic file to a strategic f=
ile.
>> Having two Perl style regimes in one tree is itself a liability.

> Honestly, I think you're reaching here.

I think that argument is wrong, actually.  Moving a function from a single
use-case into a library (with, clearly, the intention for it to have more
use-cases) is precisely the time when any weaknesses in its original
implementation might be exposed.  So extra scrutiny seems well warranted.

Whether the "extra scrutiny" involved in perlcritic's higher levels
is actually worth anything is a different debate, though, and so far
it's not looking like it's worth much :-(

			regards, tom lane