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
signature.asc
Description: PGP signature