Re: What about Perl autodie? - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: What about Perl autodie?
Date
Msg-id 24fda680-0826-42d3-a3b2-f35c59d6e771@eisentraut.org
Whole thread Raw
In response to Re: What about Perl autodie?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: What about Perl autodie?
Re: What about Perl autodie?
List pgsql-hackers
On 08.02.24 16:53, Tom Lane wrote:
> Daniel Gustafsson <daniel@yesql.se> writes:
>>> On 8 Feb 2024, at 08:01, Peter Eisentraut <peter@eisentraut.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.




pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: logical decoding and replication of sequences, take 2
Next
From: "Joel Jacobson"
Date:
Subject: Re: Document efficient self-joins / UPDATE LIMIT techniques.