CommitFest 2011-11 Post-Tryptophan Progress Report

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: CommitFest 2011-11 Post-Tryptophan Progress Report
Date: 2011-11-28 10:13:52
Message-ID: 4ED35EE0.4010706@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

With plenty of people in the US returning to work on Monday after a
modest break last week, I wanted to put out an updated on the active
CommitFest. I just sent out several pleas for help with specific patches
where only a limited chunk of the community is really in a good position
to test the code. Excluding those for the moment, here are some notes on
the submitted patches that not only don't have a reviewer already, I
don't know who might take them on yet:

"Command Triggers" by Dimitri Fontaine. This is a pretty big patch (3366
lines) that won't be easy to slug through. I know Dimitri is still
making some progress on this just by thinking more about the code, but
that's not going to keep up for much longer without outside feedback.

"type privileges" by Peter Eisentraut. Another big patch (2537 lines),
and it needs both some code review and searching for security issues in
the new feature.

Both "type privledges" and "Command Triggers" are likely to slip well
into December if we don't get a major reviewer working on them soon. I
just don't know who that might be in either case.

"cursor calling with named parameters" by Yeb Havinga. This is a
resubmission of a patch from the last CommitFest, so that previous
feedback is around to give an idea what should be re-tested in the new
version. At 702 lines including docs and tests, I'd call this a medium
sized patch to work on. It'd say it's a decent candidate for someone who
picked up a patch, got done early, and is enough of a glutton to want to
do a second patch.

"splitting plpython into smaller parts" by Jan Urbański. Just asked for
clarification on this one because I'm not quite sure what to do with it.

"unite recovery.conf and postgresql.conf": Since this has a lot more
consensus issues than code ones, I'm going to look into this more
myself. The things I submitted actually change around the potential ways
to satisfy all the use cases here, too.

"Configuration include directory" and "includeifexists in configuration
file" by me. These are not too hard to look at, and given that this all
started as hacking on Mangus's code he may get to it eventually anyway.
I'm not too worried about these two right now.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2011-11-28 10:40:39 Re: Measuring relation free space
Previous Message Greg Smith 2011-11-28 10:00:24 Re: splitting plpython into smaller parts