Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

On Thu, Mar 15, 2018 at 02:03:15PM +0900, Kyotaro HORIGUCHI wrote:
> At Thu, 15 Mar 2018 00:33:25 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in <22193(dot)1521088405(at)sss(dot)pgh(dot)pa(dot)us>
>> Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> writes:
>>> Doesn't it make sense if we provide a buildtime-script that
>>> collects the function names and builds a .h file containing a
>>> function using the list?
>>
>> Surely this is a fundamentally misguided approach. How could it
>> handle extension GUCs?
>
> I understand it is "out of scope" of this thread (for now). The
> starting issue here is "the static list of list-guc's are stale"
> so what a static list cannot cope with is still cannot be coped
> with by this.

I like the mention of the idea, now it is true that that it would be a
half-baked work without parameters from plpgsql, and a way to correctly
track parameters marking a custom GUC as GUC_INPUT_LIST in all C files.

> Or, we could cope with this issue if the list-ness of used GUCs
> is stored permanently in somewhere. Maybe pg_proc.proconfigislist
> or something...

That does not help for PL's GUCs as well. Those may not be loaded when
pg_get_functiondef gets called.

At the end, we are spending a lot of resources on that. So in order to
close this thread, I would suggest to just complete the list of
hardcoded parameters on backend and frontend, and add as well a comment
including "GUC_INPUT_LIST" so as it can be found by grepping the code.
--
Michael