Re: What about Perl autodie?
От | Andrew Dunstan |
---|---|
Тема | Re: What about Perl autodie? |
Дата | |
Msg-id | 47d9c8f8-ef89-fa21-ed20-f1079c0047bb@dunslane.net обсуждение исходный текст |
Ответ на | Re: What about Perl autodie? (Peter Eisentraut <peter@eisentraut.org>) |
Ответы |
Re: What about Perl autodie?
|
Список | pgsql-hackers |
On 2024-02-14 We 11:52, Peter Eisentraut wrote: > 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. > > Yeah, that should work. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: