On Thu, Mar 15, 2018 at 02:03:15PM +0900, Kyotaro HORIGUCHI wrote: > 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.
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
signature.asc
Description: PGP signature