Forgive me for jumping in again on discussion of a feature I might
never use, but as an "outside observer" something doesn't make sense
to me.
Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> If you require that a tool (or SET PERISTENT) parse through a file
> in order to change one setting, then you've just doubled or tripled
> the code size of the tool, as well as added a host of failure
> conditions which wouldn't have existed otherwise.
Not if there is one implementation of which is distributed with
PostgreSQL. Give it a clean API and a command-line application (for
scripting in non-C languages) and this is a non-issue. This really
seems like a red herring.
I know it would be more lines in C than a bash script; but really,
think about how little work this would be for any script which has
grep and sed available -- at least if you assume it shouldn't follow
include statements. But I think that's where the rub is -- when you
have more than one source for information, what's the precedence?
That question doesn't go away with the proposed feature. It seems
that in reading this thread I've seen a lot of conflicting notions on
how it *should* work, with a handwavy assertion that it doesn't matter
because the DBA can sort it all out. But then will the tools always
do what people expect?
It seems like there's a significant base of users who want their
database product to self-configure; and there's clearly a significant
base of professional DBAs who want to be able to hand-tune for a
variety of reasons. I assume that addressing these disparate needs is
one of the goals here? As well as an easy way to drop in
configuration for additional features? The directory seems to make
sense for the latter, but seems horrible to me for the former. It
turns the risk of a spaghetti configuration file into a sorcerer's
apprentice collection of competing, conflicting files which are a
worse mess that the spaghetti.
Perhaps there should be two separate features for the two separate use
cases?
-Kevin