Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0
От | Josh berkus |
---|---|
Тема | Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 |
Дата | |
Msg-id | 570D3D91.7050505@agliodbs.com обсуждение исходный текст |
Ответ на | Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 (Justin Clift <justin@postgresql.org>) |
Ответы |
Re: Lets (not) break all the things. Was: [pgsql-advocacy]
9.6 -> 10.0
Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 |
Список | 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 по дате отправления: