Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs
Date
Msg-id 20180316121554.GA2552@paquier.xyz
Whole thread Raw
In response to Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List pgsql-hackers
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.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Shubham Barai
Date:
Subject: Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
Next
From: Tomas Vondra
Date:
Subject: Re: [HACKERS] [PATCH] Incremental sort