Re: Should we get rid of custom_variable_classes altogether?

Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> Dimitri Fontaine <dimitri@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