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 <j...@agliodbs.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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers