Re: Storage Location Patch Proposal for V7.3 - Mailing list pgsql-hackers

From Thomas Lockhart
Subject Re: Storage Location Patch Proposal for V7.3
Date
Msg-id 3C84D007.46FB30B6@fourpalms.org
Whole thread Raw
In response to Re: Storage Location Patch Proposal for V7.3  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
...
> Forward compatibility to a future tablespace implementation.
> If we do this, we'll be stuck with supporting this feature set,
> not to mention this syntax; neither of which have garnered any
> support from the assembled hackers.

The feature set (in some incarnation) is exactly something we should
have. "Tablespace" could mean almost anything, since (I recall that) we
are not slavishly copying the Oracle features having a similar name. The
syntax (or something similar) seems acceptable to me. I haven't looked
at the implementation itself.

So, I'll guess that the particular objection to this implementation is
along the lines of wanting to be able to manage tablespaces/locations as
a single entity? So that one could issue commands like (forgive the
syntax) "move tablespace xxx to yyy;" and be able to yank the entire
contents from one place to another in a single line?

Jim's patches don't explicitly tie the pieces residing in a single
location together. Is that the objection? In all other respects (and
perhaps in all respects period) it seems to be a good starting point at
least.

I know that you have said that you want to look at "tablespaces" for
7.3. If we get there with a feature set we all find acceptable, then
great. If we don't, then Jim's subset of features would be great to
have.

Comments?
                      - Thomas


pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: [PATCHES] new hash function
Next
From: mlw
Date:
Subject: Re: Postgresql backend to perform vacuum automatically