--
dim
Le 27 oct. 2009 à 18:21, Tom Lane <t...@sss.pgh.pa.us> a écrit :
Greg Smith <gsm...@gregsmith.com> writes:
... One file per GUC is certainly never going to fly though, it's
been hard enough getting people to accept going from one file to
more than
one.
One thing that concerns me a bit about the lack of consensus on that
is what will happen if different config-adjustment tools adopt
different
philosophies. If Dimitri writes a tool that drops settings into per-
GUC
files, and you write one that puts them all in persistent.conf, and
somebody tries to use both those tools, no good will come of it.
Right, that's why Greg Stark convinced me that we're defining an API
here, not just a facility.
If we forgot about the config-dir idea and just had one file that was
meant to be hacked by automated tools, the problem would go away.
However I suspect that that proposal won't fly, so we ought to think
about providing some guidance to tools writers about what to do.
Is there any consensus on how multiple config files actually get used
over in the Apache/etc world?
What they have is different contexts where to apply the same settings.
You basically write one file per context.
As you are saying that does not translate well to our case where we
want one context and N tools.
I don't see that opening the possibility to edit the same GUC in more
than exactly 2 places is giving us anything. First the tool location,
then the local DBA hand maintained file. Which still could include
other files, as Kevin does, for park managment purpose.
The DBA friendly option is the existing include directive. includedir
buys nothing in my mind. We want a tool API and the first tool to
expose it in the form of SET PERSISTENT. I think :)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
