Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Josh berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Justin Clift <justin(at)postgresql(dot)org>, PostgreSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0
Date: 2016-04-29 16:17:39
Message-ID: CAHyXU0whDTmLxeDERC_mrVZYipXyfZT3yW3jCNQZfuMj7BP4Dg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 29, 2016 at 11:02 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 12 April 2016 at 20:25, Josh berkus <josh(at)agliodbs(dot)com> wrote:
>
>>
>> Here's the features I can imagine being worth major backwards
>> compatibility breaks:
>>
>> 1. Fully pluggable storage with a clean API.
>>
>> 2. Total elimination of VACUUM or XID freezing
>>
>> 3. Fully transparent-to-the user MM replication/clustering or sharding.
>>
>> 4. Perfect partitioning (i.e. transparent to the user, supports keys &
>> joins, supports expressions on partition key, etc.)
>>
>> 5. Transparent upgrade-in-place (i.e. allowing 10.2 to use 10.1's tables
>> without pg_upgrade or other modification).
>>
>> 6. Fully pluggable parser/executor with a good API
>>
>> That's pretty much it. I can't imagine anything else which would
>> justify imposing a huge upgrade barrier on users. And, I'll point out,
>> that in the above list:
>>
>> * nobody is currently working on anything in core except #4.
>>
>> * we don't *know* that any of the above items will require a backwards
>> compatibility break.
>>
>> People keep talking about "we might want to break compatibility/file
>> format one day". But nobody is working on anything which will and
>> justifies it.
>
> Of your list, I know 2ndQuadrant developers are working on 1, 3, 5.
> 6 has being discussed recently on list by other hackers.

#5 (upgrade without pg_upgrade or dump/restore) from my perspective
would be the most useful feature of all time, and would justify the
9.x to 10.x all by itself using the existing standard (I think?) of
major project milestones to advance that number.

7.x ?? (just coming on the scene then)
8.x windows, pitr
9.x replication
10.x easy upgrades

merlin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2016-04-29 16:40:04 Re: pg9.6 segfault using simple query (related to use fk for join estimates)
Previous Message David G. Johnston 2016-04-29 16:08:11 Re: Add jsonb_compact(...) for whitespace-free jsonb to text