At Thu, 15 Mar 2018 00:33:25 -0400, Tom Lane <t...@sss.pgh.pa.us> wrote in <22193.1521088...@sss.pgh.pa.us> > Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.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. As the discussion upthread, with the dynamic (or on the fly) approach, pg_dump fails when required extension is not loaded. Especially plpgsql variables are the candidate stopper of ordinary pg_dump operation. We might have to implicitly load the module by any means to make it work. If we treat extensions properly, we must find the extension that have defined a GUC that is about to be exported, then load it. I don't think the automatic stuff is essential but the check_listvars.h is still effective to reduce the effort needed to maintain the multiple lists that should have the same set of names of the list-gucs. 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... regards, -- Kyotaro Horiguchi NTT Open Source Software Center
