On Thu, Apr 12, 2018 at 3:39 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Apr 12, 2018 at 3:15 PM, Jonathan S. Katz > <jonathan.k...@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 > Your last example is why I proposed taking the TABLESPACE defined on the parent and applying it to the children. Then all the children have one defined and nothing breaks as long as all tablespaces are properly defined as part of the restoration. I'm also not sure that we should have this mindset of partitioning working as inheritance does either. Inheritance was only used before because it was the only mechanism available. And while you do still use it under the hood for parts of partitioning, I don't see any reason we should be let people assume that partitioning works anything like inheritance. In my opinion they are two very distinct options. Now we have "real" partitioning, so let's act like it. That doesn't mean defining old behavior as a "bug", I agree. It just means we're defining and clarifying how partitioning itself is supposed to be working. -- Keith Fiske Senior Database Engineer Crunchy Data - http://crunchydata.com
