Re: initdb mkdir_p() doesn't work - Mailing list pgsql-hackers

From Tom Lane
Subject Re: initdb mkdir_p() doesn't work
Date
Msg-id 418.1069632288@sss.pgh.pa.us
Whole thread Raw
In response to Re: initdb mkdir_p() doesn't work  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: initdb mkdir_p() doesn't work  (Andrew Dunstan <andrew@dunslane.net>)
Re: initdb mkdir_p() doesn't work  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> AFAICS mkdatadir() shouldn't consider subdir == NULL as a reason to
>> fail rather than trying mkdir_p.

> Right. In fact, I can't see any good reason to call mkdir and then 
> mkdir_p at all. See my patch from this afternoon.

I'm unsure about that.  I liked the original idea of only trying mkdir_p
when plain mkdir() had failed with ENOENT.  I am not convinced your
proposed patch will behave desirably under all error cases.  In
particular, mkdir_p seems rather dependent on knowing just which errno
codes will get returned --- which is okay for its heritage as BSD-only
code, but how well will it port?  Better to only invoke it when we have
reason to think it can help.

> Sure. Of course, the reason I put this on my web site and asked for 
> eyeballs was to try to catch some of this sort of stuff before the 
> program went into the tree :-)

We have a whole development cycle to shake these issues out.  Don't
panic.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Executable files in CVS
Next
From: Bruce Momjian
Date:
Subject: Re: Executable files in CVS