On Thu, Apr 12, 2018 at 03:39:19PM -0400, Robert Haas wrote:
> Well I don't object to updating the documentation, but just because
> something isn't what the user expects doesn't make it a bug.  Users
> can have arbitrary expectations.

Yes, I agree that this is not a bug, and should not be categorized as
such.  Mentioning in the documentation explicitely that tablespaces are
not inherited may be worth it.

> On a practical level, what I think users *should* expect is that table
> partitioning behaves like table inheritance except in cases where
> we've gotten around to doing something different.  Of course, the
> behavior of table partitioning here is no worse than what table
> inheritance does.  The behavior doesn't cascade from parent to child
> there, either.  If we start classifying as a bug every area where
> table partitioning works like table inheritance but someone can think
> of something better, we've probably got about 50 bugs, some of which
> will require years of work to fix.


> Unless done rather carefully, it's also going to break
> dump-and-restore and, I think, likely also pg_upgrade.  Suppose that
> in the original cluster TABLESPACE was set on the parent but not on
> the children.  The children are therefore dumped without a TABLESPACE
> clause.  On the old cluster that would have worked as intended, but
> with this change the children will end up in the parent's tablespace
> instead of the database default tablespace.

I have not looked at the problem closely, but now pg_dump relies heavily
on default_tablespace to make sure that a table is using the correctly
tablespace and does not append a TABLESPACE clause to CREATE TABLE so as
pg_restore can work with --no-tablespaces.  So we'll surely get some
regressions and corner cases if not careful.

Attachment: signature.asc
Description: PGP signature

Reply via email to