Dimitri Fontaine <dimi...@2ndquadrant.fr> writes:
> 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.
I still don't see the point. If they want to change the default
setting, they add an entry to postgresql.conf. Problem solved.
> 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.
This is adding even more complication to solve a non-problem.
May I remind you that a lot of people think that the default entries in
postgresql.conf for the core settings are a bad idea? Why should we
invent even more mechanism (and more conventions for users to remember)
to duplicate something of questionable value?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
