Tom,
> I'm not convinced we ever *had* a consensus on this. There were
> proposals, but I'm not sure a majority ever bought into any one of 'em.
> The whole problem of intermixing manual editing and programmatic editing
> is just a big can of worms, and not everybody is prepared to give up the
> former to have the latter.
Well, I think we have consensus that intermixing is impractical, which
is why every further proposal is around having a separate file for the
SQL-modified values. And yes, we have a certain amount of "You'll get
my carefully edited postgresql.conf when you pry it out of my cold, dead
hands" going on.
The real consensus problem, AFAICT, is that while we have consensus that
we would like something like SET PERSISTENT as an *option*, there's a
Hurricane Sandy-sized Bikeshedding Windstorm about how, exactly, people
would like it to work. Personally, I would prefer the implementation
which actually gets committed. ;-)
> You can, if you are so inclined, implement something functionally
> equivalent to Amit's proposal today using contrib/adminpack's
> pg_file_write --- okay, it's much less convenient than a built-in
> implementation would be, but you can drop some variable assignments into
> a file and then put a suitable INCLUDE into the otherwise-static main
> config file. The fact that this isn't being done by a large number of
> people (is anybody at all actually doing it?) suggests to me that maybe
> the demand isn't all that great.
It suggest nothing of the sort:
1. a tiny minority of our users even know about adminpack
2. implementing it the way you suggest would require a hacker's
understanding of Postgres, which is an even smaller minority.
On the other hand, the success of tools like Puppet have made having SET
PERSISTENT a lot less urgent for many large-scale installation managers.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com