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

From: Justin Clift <justin(at)postgresql(dot)org>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: PostgreSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0
Date: 2016-04-12 16:32:38
Message-ID: CAAF273F-DE62-42ED-B5F5-81CF6D3227E9@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12 Apr 2016, at 17:23, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Mon, Apr 11, 2016 at 11:39 AM, Justin Clift <justin(at)postgresql(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2016-04-12 16:49:25 pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Previous Message Teodor Sigaev 2016-04-12 16:30:26 Re: GIN data corruption bug(s) in 9.6devel