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

From Andres Freund
Subject Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0
Date
Msg-id 20160412182744.py3k2jie6kxioptz@alap3.anarazel.de
Whole thread Raw
In response to Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0  (Josh berkus <josh@agliodbs.com>)
Responses Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0  (Robert Haas <robertmhaas@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Josh berkus
Date:
Subject: Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0
Next
From: Robert Haas
Date:
Subject: Re: Detrimental performance impact of ringbuffers on performance