Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I think the big question is whether we want the default to install the
> configs in a separate directory, pgsql/etc, or just allow the
> specification of a separate location. Advantages of pgsql/etc are
> initdb-safe, and easier backups.
I don't see why we don't just let initdb install suggested config files
into the new $PGDATA directory, same as it ever did. Then (as long as
we don't use relative paths in the config files) people can move them
somewhere else if they like, or not if they prefer not to. Adding more
mechanism than that just adds complexity without buying much (except the
possibility of initdb overwriting your old config files, which is
exactly what I thought we wanted to avoid).
> The big question is whether PGDATA is still our driving config variable,
> and PGCONFIG/-C is just an additional option, or whether we are moving
> in a direction where PGCONFIG/-C is going to be the driving value, and
> data_dir is going to be read as part of that.
I thought the idea was to allow both approaches. We are not moving in
the direction of one or the other, we are giving people a choice of how
they want to drive it.
> Weren't you just showing how you set environment variables to easily
> configure stuff. If you use a separate configure dir, isn't PGCONFIG
> part of that?
I'm just pointing out that there's no backward-compatibility argument
for PGCONFIG. It should only be put in if the people who want to use
the -C-is-driver approach want it. Kevin clearly doesn't ;-).
regards, tom lane