Re: automating perl compile time checking
От | Andrew Dunstan |
---|---|
Тема | Re: automating perl compile time checking |
Дата | |
Msg-id | 7a31adc5-71d6-c885-789f-6550aa2ac6bd@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: automating perl compile time checking (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: automating perl compile time checking
Re: automating perl compile time checking |
Список | pgsql-hackers |
On 06/11/2018 04:01 PM, Peter Eisentraut wrote: > On 6/11/18 15:38, Andrew Dunstan wrote: >>>>> On 5 Jun 2018, at 16:31, Andrew Dunstan <andrew.dunstan@2ndquadrant.com> wrote: >>>>> The patch contains a simple script to run the checks. The code that finds perl files is put in a function in a singlefile that is sourced by the three locations that need it. >>>> +1 on centralizing the find-files function. >>> +1 on that. Why do we need to make the new find_perl_files file >>> executable, given it's always sourced? (I would have given a .sh >>> extension because it's a lib not an executable, but I suppose that's >>> just matter of taste; we certainly don't have a policy about it). >>> >>> Looks fine to me either way. >>> >> >> I've committed this, but I'm fine if people want to tweak the names. It >> probably doesn't need to be executable. > Why is this being committed after feature freeze? > This affects pretty much nothing. In fact some of the other changes I've recently committed were arguably more dangerous. Do you want me to revert the whole lot? cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: