From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Josh berkus <josh(at)agliodbs(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Justin Clift <justin(at)postgresql(dot)org>, Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Subject: | Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 |
Date: | 2016-04-12 18:27:44 |
Message-ID: | 20160412182744.py3k2jie6kxioptz@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2016-04-12 11:25:21 -0700, Josh berkus 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.
none but 2) seem likely to require a substantial compatibility break.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-04-12 18:29:10 | Re: Detrimental performance impact of ringbuffers on performance |
Previous Message | Josh berkus | 2016-04-12 18:25:21 | Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 |