Re: pg_dump is broken for partition tablespaces

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_dump is broken for partition tablespaces
Дата
Msg-id 11955.1555251404@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_dump is broken for partition tablespaces  (David Rowley <david.rowley@2ndquadrant.com>)
Ответы Re: pg_dump is broken for partition tablespaces  (David Rowley <david.rowley@2ndquadrant.com>)
Список pgsql-hackers
David Rowley <david.rowley@2ndquadrant.com> writes:
> I'd say the fact that we populate reltablespace with 0 is a bug as
> it's not going to do what they want after a dump/restore.

Well, it's not really nice perhaps, but you cannot just put in some
other concrete tablespace OID instead.  What a zero there means is
"use the database's default tablespace", and the point of it is that
it still means that after the DB has been cloned with a different
default tablespace.  If we don't store 0 then we break
"CREATE DATABASE ... TABLESPACE = foo".

You could imagine using some special tablespace OID that has these
semantics (*not* pg_default, but some new row in pg_tablespace).
I'm not sure that that'd provide any functional improvement over
using zero, but we could certainly entertain such a change if
partitioned tables seem to need it.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: Should the docs have a warning about pg_stat_reset()?
Следующее
От: David Rowley
Дата:
Сообщение: Re: pg_dump is broken for partition tablespaces