Re: CommitFest status summary 2010-01-27

Robert Haas wrote:
> Waiting for Initial Review (4)
> ==========================
> plpython3 - no reviewer yet
>   

This whole feature seems quite interesting, and I'm really impressed at 
how much work James has put into rethinking what a Python PL should look 
like.  But isn't the fact that there isn't even a reviewer for it yet 
evidence it needs more time to develop a bit of a community first before 
being considered for core?  This seems to me like the sort of patch 
you'd want to play with for a month or two before you could really have 
an informed opinion about how working with it flows compared to the 
existing implementation, and that's not going to be possible here.

> Provide rowcount for utility SELECTs

I think I can write a review for this one right now based on the 
discussion that's already happened:

-Multiple people think the feature is valuable and it seems worth exploring
-The right way to handle the protocol change here is still not clear
-There are any number of subtle ways clients might be impacted by this 
change, and nailing that down and determining who might break is an 
extremely wide ranging bit of QA work that's barely been exploring yet

That last part screams "returned with feedback" for something submitted 
to the last CF before beta to me.  As a candidate for 9.1-alpha1 where 
there's plenty of time to figure out what it breaks and revert if that 
turns out to be bad?  That sounds like a much better time to be fiddling 
with something in this area.

I would like to see the following in order to make this patch have a 
shot at being comittable:

1) Provide some examples showing how the feature would work in practice 
and of use-cases for it.
2) To start talking about what's going to break, some notes about what 
this does to the regression tests would be nice.
3) Demonstrate with example sessions the claims that there are no 
backward compatibility issues here.  I read "when you mix old server 
with new clients or new server with old client, it will just work as 
before", but until I see a session proving that I have to assume that's 
based on code inspections rather than actual tests, and therefore not 
necessarily true.  (Nothing personal, Zoltan--just done way too much QA 
in the last year to believe anything I'm told about code without a 
matching demo).
4) Investigate and be explicit about the potential breakage here both 
for libpq clients and at least one additional driver too.  If I saw a 
demonstration that this didn't break the JDBC driver, for example, I'd 
feel a lot better about the patch.

Expecting a community reviewer to do all that just to confirm this code 
change is worthwhile seems a pretty big stretch to me, and I wouldn't 
consider it very likely that set of work could get finished in time for 
this CF.

-- 
Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com  www.2ndQuadrant.com