Re: pg_dump is broken for partition tablespaces - Mailing list pgsql-hackers

From David Rowley
Subject Re: pg_dump is broken for partition tablespaces
Date
Msg-id CAKJS1f8Dp4HfmZs02P1tBhvUFWhoGYQRtqZ=R=fkNynVf8J-6Q@mail.gmail.com
Whole thread Raw
In response to Re: pg_dump is broken for partition tablespaces  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: pg_dump is broken for partition tablespaces
List pgsql-hackers
On Wed, 24 Apr 2019 at 10:26, Alvaro Herrera <alvherre@2ndquadrant.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?

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.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Pluggable Storage - Andres's take
Next
From: Michael Paquier
Date:
Subject: Re: REINDEX INDEX results in a crash for an index of pg_class since9.6