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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html