Re: Last gasp

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Greg Smith <greg(at)2ndQuadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Last gasp
Date: 2012-04-15 15:50:01
Message-ID: 9057.1334505001@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> I completely agree that somebody has to be willing to say No, since we
> all agree that the default for any patch is non-acceptance.

> My first observation is that if No is received early enough for
> something to be done, then the outcome could be different. It was not
> clear that this important patch was going to be totally refused and
> many people have expressed their surprise about that. Noah signalled
> to everybody that the FK locks patch was likely to be rejected and a
> number of us have tried hard to save that, unluckily as it turns out.
> So an early No helped people allocate their time on what they
> considered to be important. In contrast the Command Triggers and FKs
> for arrays patches received a No so late that nothing could be done.

I think this is a rather unfair summary of the history. It was clear
very early in the CF that people thought Command Triggers had major
design problems, and Dimitri was doing significant rewrites to try to
fix that. Anyone who did not think that patch was at serious risk of
not being committed simply wasn't paying attention. Given the range
of different design options that were considered, I think it's just
as well that the patch has been put off till 9.3: we will probably
get a better feature than if it had made it this time, and we will
certainly be taking less schedule risk.

I will agree that the array-FKs patch got the short end of the stick:
had we been willing to let the CF go on for another month, it would
have gotten looked at more carefully, and quite possibly committed.
But once we made the decision to cut off the CF, there was not time
to look at it closely enough. Again, to my mind this was mostly
a risk minimization decision: when you make up a fundamental feature
out of whole cloth, there's substantial risk that you didn't get the
design right. At this point we don't have enough time for the
feature to settle in and get used before 9.2 will ship and it'll be
too late to correct any design problems.

The more general point here is that the last fest of a release cycle
is the worst possible time to be landing big, destabilizing patches.
I think we ought to be conservative at this stage of the cycle, in
hopes of keeping beta phase short and predictable.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-04-15 16:01:11 Re: Last gasp
Previous Message Tom Lane 2012-04-15 15:25:12 Re: Clobbered parameter names via DECLARE in PL/PgSQL