Re: pg_dump is broken for partition tablespaces

David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> On Mon, 15 Apr 2019 at 02:16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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".

> [ quotes documents ]

I think those documentation statements are probably wrong in detail,
or at least you're misreading them if you think they are justification
for this patch. *This change will break CREATE DATABASE*.

(And, apparently, the comment you tried to remove isn't sufficiently
clear about that.)

> Alvaro is proposing to change this behaviour for partitioned tables
> and indexes. I'm proposing not having that special case and just
> changing it.

It's possible that Alvaro's patch is also broken, but I haven't had time
to review it. The immediate question is what happens when somebody makes
a partitioned table in template1 and then does CREATE DATABASE with a
tablespace option. Does the partitioned table end up in the same
tablespace as ordinary tables do?

It's entirely possible BTW that this whole business of inheriting
tablespace from the partitioned table is broken and should be thrown
out. I certainly don't see any compelling reason for partitions to
act differently from regular tables in this respect, and the more
problems we find with the idea, the less attractive it seems.

regards, tom lane