Peter Eisentraut <peter_e@gmx.net> writes:
>> It seems like it would be a whole lot "nicer" if initdb only deleted
>> the files that it attempted to create OR if the default was not to
>> delete anything.
> Okay, I could go for the former. What do others think?
It'd be a bit of a pain but I can see the problem. You certainly
shouldn't delete the $PGDATA directory itself unless you created it,
IMHO. Doing more than that would imply that initdb's cleanup
function would have to know the list of files/subdirectories that
normally get created during initdb, so as to remove only those and
not anything else that might be lying around in the directory.
That'd be a considerable maintenance headache since most of said files
are not created directly by the script...
BTW, what about collisions? Suppose the reason the initdb fails
is that there's already a (bogus) pg_log, or some such --- is
the script supposed to know not to delete it? That strikes me
as way too difficult, since now the script has to know not only
which files get created but exactly when.
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.
Something that would be a lot simpler is to refuse to run at all
if the $PGDATA dir exists and is nonempty ;-)
regards, tom lane