Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0
От | Justin Clift |
---|---|
Тема | Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 |
Дата | |
Msg-id | CAAF273F-DE62-42ED-B5F5-81CF6D3227E9@postgresql.org обсуждение исходный текст |
Ответ на | Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 (Merlin Moncure <mmoncure@gmail.com>) |
Ответы |
Re: Lets (not) break all the things. Was: [pgsql-advocacy]
9.6 -> 10.0
|
Список | pgsql-hackers |
On 12 Apr 2016, at 17:23, Merlin Moncure <mmoncure@gmail.com> wrote: > On Mon, Apr 11, 2016 at 11:39 AM, Justin Clift <justin@postgresql.org> wrote: >> Moving over a conversation from the pgsql-advocacy mailing list. In it >> Simon (CC'd) raised the issue of potentially creating a backwards-compatibility >> breaking release at some point in the future, to deal with things that >> might have no other solution (my wording). >> >> Relevant part of that thread there for reference: >> >> http://www.postgresql.org/message-id/CANP8+jLtk1NtaJyXc=hAqX=0k+ku4zfavgVBKfs+_sOr9hepNQ@mail.gmail.com >> >> Simon included a short starter list of potentials which might be in >> that category: >> >> * SQL compliant identifiers >> * Remove RULEs >> * Change recovery.conf >> * Change block headers >> * Retire template0, template1 >> * Optimise FSM >> * Add heap metapage >> * Alter tuple headers >> et al >> >> This still is better placed on -hackers though, so lets have the >> conversation here to figure out if a "backwards compatibility breaking" >> release really is needed or not. > > A couple of points here: > *) I don't think having a version number that starts with 10 instead > of 9 magically fixes backwards compatibility problems and I think > that's a dangerous precedent to set unless we're willing to fork > development and support version 9 indefinitely including major release > versions. > > *) Compatibility issues at the SQL level have to be taken much more > seriously than other things (like internal layouts or .conf issues). > > *) We need to do an honest cost benefit analysis before breaking > things. Code refactors placed on your users puts an enormous cost > that is often underestimated. I have some fairly specific examples of > the costs related to the text cast removal for example. It's not a > pretty picture. Yeah. Moving the discussion here was more to determine which items really would need a backwards compatible break. eg no other approach can be found. Seems I started it off badly, as no-one's yet jumped in to discuss the initial points. :( + Justin -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
В списке pgsql-hackers по дате отправления: