nolan@celery.tssi.com writes:
> Being able to zap a database with one or more 'rm -rf' commands assumes
> that there will be files from just ONE database permitted in any given
> tablespace, and ONLY files from that database.
I said no such thing. Look at the structure again:
$PGDATA/base/dboid/...stuff...
sometablespace/dboid/...stuff...
othertablespace/dboid/...stuff...
DROPDB needs to nuke <somepath>/dboid/ for each tablespace's associated
<somepath>. The other design simplifies DROPDB at the cost of increased
complexity for every other tablespace management operation, since you'd
need to cope with a symlink in each database for each tablespace.
Also, this scheme is at least theoretically amenable to a symlink-free
implementation, though I personally don't give a darn whether
tablespaces are supported on Windows and thus wouldn't expend the extra
effort needed to keep track of full paths. I'd want
$PGDATA/tablespaces/tboid to be a symlink to the root of the tablespace
with a given OID, and then the actual pathname used to access a table in
tablespace tboid, database dboid, table filenode rfoid would look like$PGDATA/tablespaces/tboid/dboid/rfoid
But a Windoze version could in theory keep track of tablespace locations
directly, and replace the first part of this path with the actual
tablespace location. If we put tablespaces under directories then the
facility has zero functionality without symlinks, because you couldn't
actually do anything to segregate stuff within a database across
different devices.
BTW, we'd probably remove $PGDATA/base in favor of $PGDATA/tablespaces/N
for some fixed-in-advance N that is the system tablespace, and we'd
require all system catalogs to live in this tablespace --- certainly at
least pg_class and its indexes. Otherwise you have circularity problems
in finding the catalogs ...
regards, tom lane