Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs |
Дата | |
Msg-id | 20180319.144909.253960140.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs
|
Список | pgsql-hackers |
At Fri, 16 Mar 2018 21:15:54 +0900, Michael Paquier <michael@paquier.xyz> wrote in <20180316121554.GA2552@paquier.xyz> > On Fri, Mar 16, 2018 at 09:40:18AM +0100, Pavel Stehule wrote: > > 2018-03-16 9:34 GMT+01:00 Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp > >> That's true, but doesn't the additional rule make it more > >> bothersome to maintain the list? > > > > Hard to say. I have not opinion. But just when I see in this context > > variables like listen_address, shared_preload_libraries, then it looks > > messy. > > Let's be clear. I have listed all the variables in the patch to gather > more easily opinions, and because it is easier to review the whole stack > this way. I personally think that the only variables where the patch > makes sense are: > - DateStyle > - search_path > - plpgsql.extra_errors > - plpgsql.extra_warnings > - wal_consistency_checking > So I would be incline to drop the rest from the patch. If there are > authors of popular extensions willing to get this support, let's update > the list once they argue about it and only if it makes sense. However, > as far as I can see, there are no real candidates. So let's keep the > list simple. FWIW +1 from me. It seems reasonable as the amendment to the current status. regards, -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: