Then <Michael.Ansley@intec.co.za> spoke up and said:
> >> I liked the thread about moving indexes and tables to seperate file
> >> systems, and hope we can implement something that will make it
> >> something
> >> that does't require 'ln's, but I definitely don't like Oracle's way of
> >> doing things ...
> Yes, that's about the sum of it. Why not the links? I think that it's an
> elegant way of designing the whole thing. Only the system table that stores
> the 'tablespace' directories will even have a hard path in it. For the
> rest, everything works in the main database directory (which could be
> considered the SYSTEM tablespace).
It seems to me (in spite of the fact that I contribute no code) that
we *might* want to consider if we want a system table that contains
storage manager specific information. Our current storage manager
could probably be extended (with some small amount of difficulty) to
get more path information out of such a table. A raw partition
storage manager might want pathing and sizeing information.
Back to the symlink stuff: symlinking in general should be deprecated
since it doesn't work everywhere, PLUS it causes ugliness in the table
truncation code. I must admit, I'm and Ingres fan, and I kinda like
the way it does things (very similar to what PostgreSQL does, but
explicit pathing in a system table). A database is created in a
default location, it can then be extended across multiple locations.
Without explicit instruction, however, it will create all new files in
the default location. Ingres also has the initial database lookup
function return the default database area.
--
=====================================================================
| JAVA must have been developed in the wilds of West Virginia. |
| After all, why else would it support only single inheritance?? |
=====================================================================
| Finger geek@cmu.edu for my public key. |
=====================================================================