On Thu, Apr 12, 2018 at 3:15 PM, Jonathan S. Katz
<jonathan.katz@excoventures.com> wrote:
> Behavior-wise it’s certainly a bug: you add a TABLESPACE on the parent
> table, and that property is not passed down to the children, which is not
> what the user expects. At a minimum, if we don’t back patch it, we probably
> need to update the documentation to let people know.
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.
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.
This is clearly new development aimed at delivering a novel behavior.
It isn't going to fix an error in code that already exists. It's
going to write new code to do something that the system has never done
before.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company