Re: pg_dump is broken for partition tablespaces

On 2019-Apr-24, David Rowley wrote:

> On Wed, 24 Apr 2019 at 10:26, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> > If creating a partition, there is the additional rule that parent's
> > tablespace overrides default_tablespace:
> >
> > a2. if there's a TABLESPACE clause, use that.
> > b2. otherwise, if the parent has a tablespace, use that.
> > c2. otherwise, if there's a default_tablespace, use that.
> > d2. otherwise, use the database tablespace.
> > e2. if we end up with the database tablespace, overwrite with 0.
>
> Wouldn't it just take the proposed pg_dump change to get that? rule
> e2 says we'll store 0 in reltablespace, even if the user does
> TABLESPACE pg_default, so there's no requirement to adjust the hack in
> heap_create to put any additional conditions on when we set
> reltablespace to 0, so it looks like none of the patching work you did
> would be required to implement this. Right?

I'm not sure yet that 100% of the patch is gone, but yes much of it
would go away thankfully. I do suggest we should raise an error if rule
a3 hits and it mentions the database tablespace (I stupidly forgot
this critical point in the previous email). I think astonishment is
lesser that way.

> The good part about that is that its consistent with what happens if
> the user does TABLESPACE pg_default for any other object type that
> supports tablespaces. i.e we always store 0.

Yeah, it makes the whole thing a lot simpler. Note my note for further
development of a feature (modelled after Robert's proposal) to allow the
database tablespace to be specified, using either a separate pg_tablespace
entry that means "use the database tablespace whatever that is" (Tom's
suggestion), or a magic not-a-real-tablespace-OID number known to the
code, such as 1 (Robert's).

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services