Peter Eisentraut <pete...@gmx.net> writes:
> On mån, 2010-10-18 at 15:50 -0400, Tom Lane 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.
> I'm still struggling with the above argument. In one case you are
> applying a behavior to the argument given to initdb, in the other case
> you are applying the behavior to a subdirectory of the argument given to
> CREATE TABLESPACE. I'm not saying the solution is necessarily wrong,
> but it doesn't seem that this will make things easier or more
> consistent.
Well, it is only an argument by analogy, but the proposal does fix the
IMO-clear misbehavior complained of way back at the start of this
thread.
> An idle thought: How about creating a version-subdirectory also in the
> PGDATA path. The point about mountpoint annoyance applies here just as
> well. And it could also make the directory juggling during in-place
> upgrade more normalized and robust.
I can't get excited about it. That would break every existing tool that
looks into PGDATA, for a fairly marginal simplification during version
upgrades. To give just one example of the pain we'd be letting
ourselves in for, pg_ctl would now become extremely version-specific.
You couldn't even get away with using the wrong copy of pg_ctl during a
reinstall after a catversion bump during development.
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
