Mikheev, Vadim writes:
> > I could probably go through and fix this, but I'm not fully
> > aware about the larger plan of table spaces that's apparently
> > sneaking in here (cf. RelFileNode.tblNode).
>
> This would be very appreciated. Table spaces will be in 7.2,
> hopefully. For the moment tblNode is just database OID
> (InvalidOid for shared relations).
I think we have a bit of a problem here. In order to restore the
previously existing alternative location feature we'd somehow have to
stick this information into RelFileNode. Firstly, alternative locations
were referenced as text strings (usually environment variable names),
which doesn't seem appropriate to stick into RelFileNode. We could make a
separate system catalog (as I have suggested several times) to assign oids
to these locations.
But RelFileNode already claims to store the identity of the table space,
being the database oid. This doesn't work because a location can contain
more than one database. So effectively we'd need to redefine RelFileNode
something like 'struct { locationid, dbid, relid }'.
I'm afraid I feel incompetent here. RelFileNode is used in too many
places that I don't understand.
> I think that to handle locations we could symlink catalogs - ln -s
> path_to_database_in_some_location .../base/DatabaseOid
But that's a kludge. We ought to discourage people from messing with the
storage internals.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
