Re: Native partitioning tablespace inheritance - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Native partitioning tablespace inheritance
Date
Msg-id 20180413224007.GB27295@paquier.xyz
Whole thread Raw
In response to Re: Native partitioning tablespace inheritance  (Evgeniy Shishkin <itparanoia@gmail.com>)
List pgsql-hackers
On Fri, Apr 13, 2018 at 08:23:22PM +0300, Evgeniy Shishkin wrote:
>> On Apr 13, 2018, at 20:01, Robert Haas <robertmhaas@gmail.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

Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: partitioning code reorganization
Next
From: David Arnold
Date:
Subject: Proposal: Adding json logging