[EMAIL PROTECTED] 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. There are a bunch of interesting locking issues to be solved, but the storage layout ideas are pretty clear in my mind. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend