Re: Explicit config patch 7.2B4

Tom Lane wrote:
>
> Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> > I'll have to echo Mark's query, though: Why are you fighting this, Peter?
>
> Peter's not the only one who's unhappy.

I still do not understand why.

>
> > This functionality mirrors the standard behaviour for daemons.
>
> That's been Mark's primary argument all along, and what it ignores is
> that the standard behavior for daemons is designed around the assumption
> that a system is running only one copy of any given daemon. That's a
> fine assumption for most daemons but an unacceptable one for Postgres.

It makes NO such argument at all! It allows an admin to explicitly share a
configuration file (or not). I allows for one central place in which multiple
configuration files can be stored and backed up. It allows for the explicit
sharing of pg_hba.conf files. (It was noted that pg_ident.conf should be added,
I am looking at it.)

Most of all it does these things WITHOUT symlinks. Most admins I know like
symlinks as a method of working around a short coming in a product, but would
rather have the configurability designed into the product.

I wrote this patch to make it easier for me to administer multiple databases on
one machine. To make it easier for UNIX admins to follow the dba's trail. I
wrote this so a system was a bit more self documenting without having to follow
symlinks.

>
> I'm prepared to accept some kind of compromise on this issue, but I'm
> really tired of hearing the useless "other daemons do it this way"
> argument. Could we hear some more-relevant argument?

This something else I don't understand. Why would you NOT give an admin the
sort of configurability they expect?

>
> I rather liked Peter's idea of treating the feature as an implicit
> inclusion. Maybe there's an even-better approach out there, but so far
> that's the best idea I've heard.

In my eyes, "implicit" means unexpected. I love the idea of an include
directive, that is a great idea, but it does not address the separation of data
and config.

People new to PostgreSQL will look for he config in /usr/local/pgsql/etc, but
it won't be there. You can specify the config directory with configure
(sysconfdir), but it is never used.

>
> > Name a standard daemon package other than postgresql that
> > automatically assumes the config is with dynamic data, and overwrites
> > an existing config when the dynamic data area is reinitialized.
>
> initdb will not overwrite an existing config. Try it.

That's good to know.

>
> > However, it wouldn't surprize me in the least for a distributor
> > such as Red Hat to apply this patch.
>
> Oh, I doubt it...

Tom, I really don't understand the resistance. It seem irrational to me, and I
am really trying to figure it out.

Obviously you must have your reasons, but all I've read thus far is the
argument that "PostgreSQL is different than other daemons." Maybe I'm pushing
too hard for this and making people defensive, but I just don't get it.

The core reasons for this patch:
(1) Move configuration out of $PGDATA and into some centralized location. I do
not know of a single admin that would object to this.
(2) Allow admins to share the pg_hba.conf file.

I try to get pg_ident when I get a chance, that's a good idea.

The one thing about this I do not like is that it is a "share all" or "share
none" solution. An include directive would be helpful here, but I think it is a
good start.