I wrote:
> I'd be willing to jump this way if we can work out the
> default-tablespace inconsistencies that Bruce has on the open items
> list.
After further thought it seems to me that using a default_tablespace
GUC variable doesn't eliminate all the open issues. In particular
it is no help for the problem of merging two different tablespaces
during CREATE DATABASE, ie, creating a new DB with a dattablespace
that is different from the template DB's default when the template
DB already has some tables explicitly placed into that tablespace.
In this situation we have the problem that the cloned DB would
have pg_class rows with different references to the same tablespace
(either zero for the database default, or the explicit OID of the
tablespace). Among other things this would make it impossible to
use the cloned DB again as a template for CREATE DATABASE.
AFAICS this problem stems ultimately from the choice to have a
special representation (zero) in pg_class for the database's default
tablespace. The only way to really get rid of it would be to eliminate
that provision and say that pg_class.reltablespace is always the correct
explicit OID. What that would mean in turn is that we could not copy a
database and move its tables into a different tablespace, at least not
without very major work on CREATE DATABASE to make it alter pg_class
on-the-fly while copying.
We might want to think about doing that eventually, but for now I'd
say that the restriction on merging tablespaces is just something
we have to live with. It's less annoying than not being able to
relocate a database, for sure.
Despite this, the default_tablespace GUC variable seems more attractive
than what we have now. Last call for objections ...
regards, tom lane
