Hi,
Phone quoting again...
--
dim
Le 27 oct. 2009 à 18:06, Greg Smith <gsm...@gregsmith.com> a écrit :
On Tue, 27 Oct 2009, Dimitri Fontaine wrote:
I parse the current status as always reading files in the
postgresql.conf.d directory located in the same place as the current
postgresql.conf file.
Way upthread I pointed out that what some packagers have really
wanted for a while now is to put the local postgresql.conf changes
into /etc rather than have them live where the database does.
Allowing the directory to be customized makes that possible. The
idea is to improve flexiblity and options for DBAs and packagers as
long as it's not difficult to implement the idea, and allowing for a
relocatable config directory isn't that hard.
Well choising where to store postgresql.conf is already possible and
what debian is doing. My proposal is to build on this: add .d and you
find the directory.
Tom had a reserve about allowing the user the control the overloading
behavior, but it appears that what we're trying to provide is a way
for
tools not to fight against DBA but help him/her. So Greg Stark's
idea do
sounds better: .d/ files are read first in alphabetical order,
then postgresql.conf is read. If the DBA want to manually edit the
configuration and be sure his edit will have effect, he just edits
postgresql.conf. No wondering.
We're trying to make allowances and a smooth upgrade path for old-
school users who don't want to use this approach. At the same time,
let's be clear: people who do that are going to find themselves
increasingly cut-off from recommended pracice moving forward. I
want to make it possible for them to continue operating as they have
been, while making it obvious that approach is on its way out.
Historic file loaded last fullfills the need in my mind.
If you want a future where it's easier for tools to operate, the
config directory goes last and overrides anything put in the primary
postgresql.conf in the default config. Having it inserted as an
explicit includedir line lets the DBA move it to the front
themselves if they want to. One thing we cannot do is make the
includedir line implicit. It must be the case that someone who
opens a new postgresql.conf file and browses it sees exactly what's
being done, so they can disable it or move the order it happens in
around.
include directive or hardwired documented rule: in either case you
know what happens when. In one case you can choose, at the expense of
having to discover local setup rather than knowing your docs.
What I have in mind is for SET PERSISTENT to warn users when settings
source is postgresql.conf.
The regexp is still to be agreed upon, [0-9a-zA-Z-_.]+.conf or sth.
This is being left to the author of the code to decide. There's
reason to believe that *.conf is going to be hard enough to
implement, and that's acceptable. If it turns out that it's easier
than expected to make a full regex syntax possible here, maybe this
should get revisited on next review.
Yes. But full regexp makes it harder for tools than hardwired rules.
Then the pg_settings view could also embed the comments.
That whole bit you outlined is an interesting idea, but it doesn't
impact this patch so I'd rather not see it drag discussion out
further right now.
Ok if the goal is include dir.
If tools and modules are concerned, it Will be easier to SET
persistent variable classes then create files like
preprepare.at_init.conf e.g.
This problem should be seen as an API problem for only automated
tools, I think, like Greg Stark said.
00-initdb.conf if you want some bikesheding to happen
That's a future patch anyway, we can bikeshed more after it's been
submitted. 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.
--
* Greg Smith gsm...@gregsmith.com http://www.gregsmith.com
Baltimore, MD
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
