On Tue, Jun 9, 2009 at 10:31 AM, Roland Hughes
<roland@logikalsolutions.com> wrote:
With RDB on OpenVMS, designed correctly, you lose nothing. Users and rights identifiers are provided by the OS as it integrates into the AUTHORIZE system. Single and multi-file databases are scattered about the entirety of the Files-11 storage system. You simply need to tell the RDB monitor about them again if you want them opened and available at system boot. If not, your application opens them on-demand.
With less than enterprise quality solutions, in particular, those that roll their own security and don't participate with the OS provided distributed transaction manager, you are quite screwed.
It shouldn't require any restructuring. Earlier in this thread someone said that if the PG root was still there when a new version was installed it was used and not initialized. So, part of the logic already exists. The only piece which needs development is the piece which skips the "init" portion of CREATE TABLESPACE when an existing tablespace is found, but continues on adding it to the default tablespace.
In short, one just needs the option to "skip a step" when issuing CREATE TABLESPACE.
That's actually not true. Consider the commit log (pg_clog) as one example. You would need to manually create the record of every commit for each transaction that exists in your tablespace, you could do this, but you'd need to be sure that you were correct. There's also the issues of XID's. All of the XID's in your tablespace are going to be well out of sync with the rest of the rdbms. Since the MVCC system is based on those xid's, the visibility of your data would be all off, unless you made restructuring to the RDBMS or your data files.
--Scott
Roland Hughes
President
Logikal Solutions
(815)-949-1593 voice
(630)-205-1593 cell
