Tom Lane <t...@sss.pgh.pa.us> writes: > Dimitri Fontaine <dimi...@2ndquadrant.fr> writes: >> What I have in mind for extensions now that c_v_c is out would be to be >> able to declare any GUC in the control file, with default values, and >> without forcing extension to handle the GUC in its .so — I don't think >> we have to change the code beside removing the c_v_c checks here. > > What's the point of that? A value in an extension control file isn't > particularly easily accessible. You'd basically only see it when > loading the extension, and that's a scenario in which the existing > mechanism works just fine. I see no reason to break existing code > here.
It's not about the code behavior but user support and packaging. That the code does the right DefineCustom calls is very good, but users should be able to easily alter defaults after installing an extension. And you're right, putting the setup into the control file is not providing that. We could have some extension.conf file. Appending to postgresql.conf is not possible from a third-party package per debian's policy, so having extension/foo.conf instead would make sense here. But at this point, it's nothing you need to care right now in your patch I guess, unless you're motivated enough :) Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
