Bruce Momjian <[EMAIL PROTECTED]> writes:
> So, we add data_dir to postgresql.conf, and add -C/PGCONFIG to
> postmaster.
Wait one second. You are blithely throwing in a PGCONFIG variable
without any detailed proposal of exactly how it will work. Does
that override a PGDATA environment variable? How do they interact?
Also, please note Kevin Brown's nearby arguments against using PGDATA
at all, which surely apply with equal force to a PGCONFIG variable.
Now, I don't buy that Kevin's arguments are enough reason to break
backwards compatibility by removing PGDATA --- but I think they are
enough reason not to introduce a new environment variable. PGCONFIG
wouldn't offer any backwards-compatibility value, and that tilts the
scales against it.
> Regarding Tom's idea of replacing data_dir with a full path during
> initdb, I think we are better having it be relative to the config
> directory, that way if they move pgsql/, the system still works.
Good thought, but you're assuming that initdb knows where the config
files will eventually live. If we do that, then moving the config
files breaks the installation. I think it will be fairly common to
let initdb drop its proposed config files into $PGDATA, and then
manually place them where they should go (or even more likely,
manually merge them with a prior version). Probably better to force
datadir to be an absolute path in the config file. (In fact, on safety
grounds I'd argue in favor of rejecting a datadir value taken from the
config file that wasn't absolute.)
> I also think we should start telling people to use PGCONFIG rather than
> PGDATA. Then, in 7.5, we move the default config file location to
> pgsql/etc, and tell folks to point there rather than /data.
I agree with none of this. This is not improvement, this is only change
for the sake of change. The packagers will do what they want to do
(and are already doing, mostly) regardless.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
