Re: 9.6 -> 10.0
От | Jim Nasby |
---|---|
Тема | Re: 9.6 -> 10.0 |
Дата | |
Msg-id | 570AE058.7030801@nasby.net обсуждение исходный текст |
Ответ на | Re: 9.6 -> 10.0 (Justin Clift <justin@postgresql.org>) |
Ответы |
Re: 9.6 -> 10.0
(Simon Riggs <simon@2ndQuadrant.com>)
Re: 9.6 -> 10.0 ("Joshua D. Drake" <jd@commandprompt.com>) |
Список | pgsql-advocacy |
On 4/9/16 2:07 PM, Justin Clift wrote: >> Do we even have a list of things we'd like to do that would break compatibility? I haven't seen one... > Simon's email a few weeks ago is probably a decent starting point: > > http://www.postgresql.org/message-id/CANP8+jLtk1NtaJyXc=hAqX=0k+ku4zfavgVBKfs+_sOr9hepNQ@mail.gmail.com > > From that: > > * SQL compliant identifiers > * Remove RULEs > * Change recovery.conf > * Change block headers > * Retire template0, template1 > * Optimise FSM > * Add heap metapage > * Alter tuple headers I think there needs to be some discussion on a larger list (ie: -hackers) about this. I had been thinking along the lines of things that would break pg_upgrade, not stuff that changes user APIs. It would be difficult enough to get agreement on breaking pg_upgrade; I doubt a release that breaks practically every tool created for Postgres is going to get concensus, regardless of the version numbering. I've tried (unsuccessfully) 3 times now to write an email starting that discussion. I think this is an important topic that needs to be discussed, but it's not clear how to even get that ball rolling. Even without the inevitable flood of "Have you lost your mind?" type replies, I don't that we even have a robust enough process to make an intelligent decision. Sure, there could be wiki pages or something about this, but those won't move discussion by themselves. Maybe the first question that needs to be answered is how we can actually move the community to an informed decision about this. One thought did occur to me though... ISTM that since 10 is a big milestone that should be celebrated that it's actually a bad target for a major compatibility break. It would be better to do that with 11. I think the timing probably works better too, 'cause I'd be amazed if we were even able to get through that laundry list of issues in 2 years, let alone 1. -- Jim C. Nasby, Data Architect jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net
В списке pgsql-advocacy по дате отправления: