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

From Tom Lane
Subject Re: pg_dump is broken for partition tablespaces
Date
Msg-id 21097.1555957836@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump is broken for partition tablespaces  (Andres Freund <andres@anarazel.de>)
Responses Re: pg_dump is broken for partition tablespaces
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2019-04-22 14:16:28 -0400, Alvaro Herrera wrote:
>> I think we can get out of this whole class of problems by forbidding the
>> TABLESPACE clause for partitioned rels from mentioning the database
>> tablespace -- that is, users either mention some *other* tablespace, or
>> partitions follow default_tablespace like everybody else.  AFAICS with
>> that restriction this whole problem does not arise, and the patch may
>> become simpler.  I'll give it a spin.

> Why is the obvious answer is to not just remove the whole tablespace
> inheritance behaviour? It's obviously ambiguous and hard to get right.
> I still don't see any usecase that even comes close to making the
> inheritance useful enough to justify the amount of work (code, tests,
> bugfixes) and docs that are required.

Yeah, that's where I'm at as well.  Alvaro's proposal could be made
to work perhaps, but I think it would still end up with some odd
corner-case behaviors.  One example is that "TABLESPACE X" would
be allowed if the database's default tablespace is Y, but if you
try to dump and restore into a database whose default is X, it'd be
rejected (?).  The results after ALTER DATABASE ... SET TABLESPACE X
are unclear too.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: block-level incremental backup
Next
From: Andres Freund
Date:
Subject: Re: block-level incremental backup