Re: What about Perl autodie?

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: What about Perl autodie?
Дата
Msg-id 24fda680-0826-42d3-a3b2-f35c59d6e771@eisentraut.org
обсуждение исходный текст
Ответ на Re: What about Perl autodie?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: What about Perl autodie?
Re: What about Perl autodie?
Список 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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: logical decoding and replication of sequences, take 2
Следующее
От: "Joel Jacobson"
Дата:
Сообщение: Re: Document efficient self-joins / UPDATE LIMIT techniques.