Re: event trigger API documentation?

On Wed, Apr 17, 2013 at 3:20 PM, Dimitri Fontaine
<dimitri(at)2ndquadrant(dot)fr> wrote:
> Please also note that the first series of patches did include the
> support code for all the core PL, but Robert didn't feel like commiting
> that and no other commiter did step up.

Of course, the chances of that would have been a lot higher had you
actually resubmitted the patches for other PLs as separate patches as
I suggested. It's asking a bit much to suppose that some other
committer was going to go root back through the old patches, extract
the portion that applied to the PL they know something about, revise
it to match the other changes that were made subsequent to the last
patch version that incorporated those changes, and then commit it,
without so much as a CommitFest entry to point them in the right
direction.

> I'm struggling to understand how to properly solve the problem here from
> an organisation perspective. Before beta was not the good time for the
> people involved, and was not the good time for other people to get
> involved. Beta is not the good time to fix what couldn't be done before.

Event triggers are suffering from the same problem as materialized
views and CRCs: stuff that gets committed in the last CommitFest tends
to be big and buggy. We could fix that problem by having one more
CommitFest where we only accepted small patches, but then people would
just try to force large patches into it after all, on the theory that
they were almost done in the previous CommitFest or weren't, really,
all that big (attachment: 30kB patch file).

No matter what we do, there's always going to be some pain around the
end of the development cycle. It's painful to see work that feels
nearly done get its release date bumped by a year. And yet it's also
painful to squeeze it in and find that there are still loose ends that
you just don't quite have time to fix. You can phrase that problem in
a way that makes it sound like it's about project policy or committers
being jerks, but I think it's mostly just that deadlines suck. I have
yet to work in a development organization - EnterpriseDB included -
that suffered any less agita around release deliverables than the
PostgreSQL community does. There are always - always! - people who
want to slip the schedule to fit more into the release, people who
want to slip more into the release WITHOUT slipping the schedule (thus
upping the defect count), and people who want to stick to the schedule
at any cost (and even if it means dumping the feature personally
requested by God Himself). And, all the intermediate positions, too.
All of those camps are as well-represented on pgsql-hackers as
anywhere else.

It is not as if any patches submitted now are going to go away. We
will presumably have a CommitFest sometime in the next couple of
months during which whatever didn't make it into 9.3 can go into 9.4
(or maybe, as I suspect, 10.0). Peter's complaint is legitimate, but
it's not a stop-ship issue for 9.3, and the next train will be along
shortly. I know that you're disappointed in how much got done with
this feature for 9.3, but I think it will have more use cases than you
realize, and the next version can and will be even better. Sure, in
some ideal world, we could have done more, but you, I, and Alvaro all
put a hell of a lot of work into this feature just to get it where it
is, and I think we should take some significant pride in making as
much progress as we did. If you'd asked me 2 years ago when
PostgreSQL would have a feature of this type, my money would have been
on NEVER.

...Robert