On Fri, 18 Jul 2003, Bruce Momjian wrote:
> Tom Lane wrote:
> > nolan@celery.tssi.com writes:
> > > I disagree. Just as you can have multiple schemas within one database
> > > you can have multiple tablespaces within one database.
> >
> > > And the tablespace is irrelevant as far as specifying an object is concerned.
> > > A fully qualified object would be:
> > > database.schema.object,
> > > not tablespace.database.schema.object or database.tablespace.schema.object.
> >
> > Right, the tablespace structure is really orthogonal to the
> > database/schema structure.
> >
> > I would envision tablespaces as being named by database-cluster-wide
> > names, just as users and groups are. Any given table could be placed
> > in any tablespace (although perhaps we want to invent some permission
> > mechanism here).
> >
> > Physically a tablespace is a directory with sub-directories for
> > databases under it --- so $PGDATA/base plays the role of the default
> > tablespace for a cluster. (The reason you need per-database
> > sub-directories is mostly to support DROP DATABASE, which has to be
> > able to nuke a database without knowing exactly what's in it.) But
> > this structure doesn't have anything to do with the logical structure
> > of the database cluster.
>
> Another good reason for per-database directories under the tablespace is
> to prevent directories from containing too many files.
I have a 3/4s finish implementation of table spaces. Per database
directories under the table space are required because CREATE DATABASE
just copies the data directory of the template database. If the databases
were in the same table space, they would need to share system catalogs
and it would also not be possible to create a database in a new table
space because the pg_class and pg_namespace would have references to the
table spaces used by the template database, not the new table space.
I will elaborate further when I have a near complete patch.
Thanks,
Gavin