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.
+1.
> 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.
--
Michael