Re: smart shutdown at end of transaction (was: Default mode for shutdown)

On Sun, Apr 29, 2012 at 5:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> "Erred on the side of progress" might even be a little strong, because
>> I think for the most part we have been extremely judicious about
>> backward incompatibilities in the last few releases (which is a good
>> thing).  Obviously, 8.3 was a flag day of the first magnitude, and one
>> I hope we won't repeat any time soon, but if you look through the
>> release notes for, say, 9.1, just about every "incompatibility" listed
>> there amounts to fixing something that was either demonstrably broken
>> or widely hated in prior releases.
>
> Well, if you're ragging on the implicit coercions changes, let me point
> out that those were also fixing something that was demonstrably broken.

True, but it was painful for a lot of people, and I continue to think
that we broke too many reasonable cases.

> So I'm afraid it's a tad pollyanna-ish to claim that there is never
> going to be push-back on changes we choose to make for one or another
> of these reasons.

Agreed, I expect some push-back. I'm just pointing out that we reject
a very significant number of changes on backward-compatibility
grounds. We don't reject too many entire patches on these grounds,
but many are the patch authors who have been asked to change X,Y, or Z
to avoid breaking backward compatibility, or who have had things
ripped out by the committer for such reasons. Of course this is
sometimes an occasion for complaint, and then the backward
compatibility changes that do get through are also an occasion for
complaint, so there's no perfect world, but we do try pretty hard, I
think.

> Having said that, though, I agree that we have to be willing to make
> incompatible changes from time to time, and I think our standards for
> when to do that are plenty high enough already.  I'm not in favor of
> raising that bar still more.  The reason we support back branches as
> long as we do is precisely to give people the option to not deal with
> incompatible changes until they are ready to.  I don't think we need
> to do even more, and I don't want to add still more overhead to the
> development process to do it.

+1, and well put.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company