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

From Josh berkus
Subject Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0
Date
Msg-id 570D3D91.7050505@agliodbs.com
Whole thread Raw
In response to Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0  (Justin Clift <justin@postgresql.org>)
Responses Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0  (Andres Freund <andres@anarazel.de>)
Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0  (Oleg Bartunov <obartunov@gmail.com>)
Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0  (Bruce Momjian <bruce@momjian.us>)
Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On 04/12/2016 10:43 AM, Robert Haas wrote:
> 1. Large backward compatibility breaks are bad.  Therefore, if any of
> these things are absolutely impossible to do without major
> compatibility breaks, we shouldn't do them at all.

+1

> 2. Small backward compatibility breaks are OK, but don't require doing
> anything special to the version number.

+1

> 3. There's no value in aggregating many small backward compatibility
> breaks into a single release.  That increases pain for users, rather
> than decreasing it, and slows down development, too, because you have
> to wait for the special magic release where it's OK to hose users.  We
> typically have a few small backward compatibility breaks in each
> release, and that's working fine, so I see little reason to change it.

+1

> 4. To the extent that I can guess what the things on Simon's list
> means from what he wrote, and that's a little difficult because his
> descriptions were very short, I think that everything on that list is
> either (a) a bad idea or (b) something that we can do without any
> compatibility break at all.

+1

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.

--
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Optimization for updating foreign tables in Postgres FDW
Next
From: Andres Freund
Date:
Subject: Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0