Re: What about Perl autodie?

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: John Naylor <johncnaylorls(at)gmail(dot)com>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: What about Perl autodie?
Date: 2024-02-19 00:54:37
Message-ID: 47d9c8f8-ef89-fa21-ed20-f1079c0047bb@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2024-02-14 We 11:52, Peter Eisentraut wrote:
> On 08.02.24 16:53, Tom Lane wrote:
>> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>>>> On 8 Feb 2024, at 08:01, Peter Eisentraut <peter(at)eisentraut(dot)org>
>>>> wrote:
>>>> I suppose we could start using it for completely new scripts.
>>
>>> +1, it would be nice to eventually be able to move to it everywhere
>>> so starting
>>> now with new scripts may make the eventual transition smoother.
>>
>> I'm still concerned about people carelessly using autodie-reliant
>> code in places where they shouldn't.  I offer two safer ways
>> forward:
>>
>> 1. Wait till v16 is the oldest supported branch, and then migrate
>> both HEAD and back branches to using autodie.
>>
>> 2. Don't wait, migrate them all now.  This would mean requiring
>> Perl 5.10.1 or later to run the TAP tests, even in back branches.
>>
>> I think #2 might not be all that radical.  We have nothing older
>> than 5.14.0 in the buildfarm, so we don't really have much grounds
>> for claiming that 5.8.3 will work today.  And 5.10.1 came out in
>> 2009, so how likely is it that anyone cares anymore?
>
> A gentler way might be to start using some perlcritic policies like
> InputOutput::RequireCheckedOpen or the more general
> InputOutput::RequireCheckedSyscalls and add explicit error checking at
> the sites it points out.  And then if we start using autodie in the
> future, any inappropriate backpatching of calls lacking error checks
> would be caught.
>
>

Yeah, that should work.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sutou Kouhei 2024-02-19 01:02:52 Re: Why is pq_begintypsend so slow?
Previous Message Amit Langote 2024-02-19 00:03:58 Re: Running the fdw test from the terminal crashes into the core-dump