Re: cleaning perl code

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: cleaning perl code
Дата
Msg-id 4426.1587045226@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: cleaning perl code  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Ответы Re: cleaning perl code
Список pgsql-hackers
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 failure by
>> moving a function, verbatim, from a non-strategic file to a strategic file.
>> 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Luo
Дата:
Сообщение: "cache reference leak" issue happened when using sepgsql module
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: Autovacuum on partitioned table (autoanalyze)