Re: Should we get rid of custom_variable_classes altogether? - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Should we get rid of custom_variable_classes altogether?
Date
Msg-id m2ty7ohjm4.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: Should we get rid of custom_variable_classes altogether?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Should we get rid of custom_variable_classes altogether?
List pgsql-hackers
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.

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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Bug with pg_ctl -w/wait and config-only directories
Next
From: jreidthompson
Date:
Subject: Re: Bug with pg_ctl -w/wait and config-only directories