>> A slightly more reasonable example is where the admin has already
>> inserted his own pg_hba.conf in the directory; would be nice if initdb
>> didn't overwrite it (nor delete it on failure), but I'm not sure it's
>> worth the trouble.
>
>I am inclined to leave it as is too. I can imagine many bug reports if
>that directory is not flushed on failure.
>
I'm no expert on shell scripts, but couldn't the current initdb script be
wrapped by something like:
if exists PG_DATA directory {
create a file listing all of the filenames currently in the directory
called "pre-existing.files"
}
current initdb script ...
if exists "pre-existing.files" {
delete all files in PG_DATA dir except those in pre-existing.files
}
The reason that IMHO this deserves a little consideration (i.e., doing it at
all rather than just saying "Don't store any files in PG_DATA") is that
RedHat based rpm installations create the postgres superuser account as part
of the process and set the home directory for this user to PG_DATA. I do a
lot of remote administration of Postgresql systems and frequently telnet
into them as user postgres which leaves me in the PG_DATA directory. I'll
upload a file or two and not really think about where I am.
I don't personally know what the effect of already having the postgres user
account set up with a different home directory does to an RPM. Perhaps the
rpm maintainer could create the postgres user account with a home directory
of /home/postgres instead of PG_DATA?
Anyway, my 0.02 dollar's worth.
len morgan