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(at)2ndQuadrant(dot)com www.2ndQuadrant.com