I'm finally getting around to something that's been on my todo list for
a couple of months.
I wrote:
> Basically, I'm thinking that given CREATE TABLESPACE LOCATION '/foo/bar'
> the creation and properties of /foo/bar/PG_9.0_201004261 ought to be
> handled *exactly* the way that the -D target directory of initdb is.
> We have more than ten years experience behind the assertion that we're
> dealing with that case in a good way. We should transfer that behavior
> over to tablespace directories rather than inventing something that
> works a shade differently.
> Barring objections, I'll go make it work that way in HEAD and 9.0.
Looking at initdb, there's a couple of hundred lines worth of code
involved here. Some of it is not directly sharable with the backend
because of the way it manages error cases, but at least the two
functions mkdir_p() and check_data_dir() could conceivably be put
into src/port/. The former is about 100 lines and the latter about 50.
Is sharing them worth doing, or should I just copy-and-paste into
commands/tablespace.c? If we're not sharing mkdir_p in toto, I'd be
inclined to not bother with duplicating initdb's willingness to create
parent directories --- it's not clear to me that that's very sensible
for a tablespace creation command anyway.
Another question is whether we're really hot enough about this to
back-patch the change into 9.0. Given the lack of other complaints
since October, maybe we shouldn't take any risk here. Messing around
with new modules in src/port/ would be more appetizing if it's HEAD
only.
Thoughts?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
