Bruce Momjian <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster