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
|
Список | 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 по дате отправления: