Dimitri Fontaine wrote:
Le mercredi 20 février 2008, Magnus Hagander a écrit :
What about having a postgresql.conf.d directory containing a file per
setting, maybe with a subdir per section. If I take Josh Berkus example,
we'd have
<snip>
IMHO, if we do that it really sucks for those who use manual configuration
files, to the point of being completely unusable. It could be valid if we
want to support config only through the API, but that's not what people are
asking for.
We need something that's low-impact for existing users, and this certainly
isn't.
What about having PG still able to load postgresql.conf or the tree of config
files, automatically, erroring when both mechanisms are in use at the same
time. This would allow for manual config editing installations and SQL
embedded configuration setting, just not in the same cluster at the same
time.
I see how the proposal fails to answer to people wanting to edit the same
configuration both with a file editor and SQL commands, but maybe having
either postgresql.conf or SQL interface for configuration could be a first
step?
No. Seriously. We need to have reasonable manual editability preserved
for all cases. The tree of files proposal just strikes me as a basic
non-starter, and, frankly, a piece of bad design. If you need structure,
then using the file system to provider it is just a bad move.
All this discussion seems to me to be going off into the clouds, where
every objection is met with some still more elaborate scheme. I think we
need to look at simple, incremental, and if possible backwards
compatible changes.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
