Tom Lane <tgl@sss.pgh.pa.us> writes:
> I still don't see the point. If they want to change the default
> setting, they add an entry to postgresql.conf. Problem solved.
As you wish. They will have to figure the current defaults in some
other way then edit the file. That's good enough for now anyway.
>> 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.
Mmm. Ok.
> 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?
It could be the timing when I try to sell my idea of one file per GUC,
then extensions would simply add a bunch of files in there. The value
of doing one GUC per file is not having to parse anything, the first non
line is the value, the rest of the file free form comments.
With this model, there's no new setup mechanism.
But anyhow, all that can wait until after you get rid of
custom_variable_classes, I think we're talking about what could happen
next here, if anything.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
