Re: Should we get rid of custom_variable_classes altogether?

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)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