Re: Native partitioning tablespace inheritance

On Fri, Apr 13, 2018 at 08:23:22PM +0300, Evgeniy Shishkin wrote:
>> On Apr 13, 2018, at 20:01, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>
>> Well, let me put it this way. Someone who assumes that partitioning
>> works like inheritance except where we've explicitly made it work
>> differently will be correct. Someone who assumes something else will
>> be incorrect. I'm not saying that we shouldn't change things in the
>> future. I think there's a lot of opportunity for improvement.
>> However, I also think that partitioning shouldn't get to ignore the
>> feature freeze deadline. There's been a huge amount of progress in
>> this release: faster pruning, run-time pruning, indexes, foreign keys,
>> triggers, hash partitioning, default partitioning, update tuple
>> routing, partition-wise join & aggregate, and other things. What
>> didn't get done should, in my opinion, wait for v12. I know that's
>> painful, but IMHO you've got to draw the line someplace, and we picked
>> a date and should stick with it.

+1. There are maaany things to test and look at, so the focus should be
in stabilizing the release.

> Yeah, but the more we wait, the more painful would be the change of behavior.
> Just like with CTE there would be more people arguing that users now rely on it.

There is room for development in v12 and beyond if there are thoughts
that this behavior should be changed. The amount of features of v11 is
now sealed, the future is not.
--
Michael