Re: CommitFest status summary 2010-01-27 - Mailing list pgsql-hackers

On Wed, Jan 27, 2010 at 11:13 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> Robert Haas wrote:
>> 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?

I agree.  I think this needs to live outside of core for the time
being.   I don't think we can commit to maintaining a second PL/python
implementation in core because two or three people are excited about
it.  It may be really great, and if there are some small changes to
core that are needed to support this living outside of core, then I
think we should consider those.  But committing the whole patch does
not seem like a wise idea to me.  We are then on the hook to maintain
it, essentially forever, and it's not clear that there is enough
community support for this for us to be certain of that.  If the
community around this grows, we can certainly revisit for 9.1.

>> 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 feel a bit differently about this.  No matter when we make a change
like this, there will be some risk of breaking clients.  Many of those
clients may be proprietary, closed-source software, and we have no way
of estimating how many such clients there are in total nor what
percentage of them are likely to be broken by this change.   Looking
at a few of the open source clients and trying to judge whether they
will break may be worthwhile, but I think the primary thing we need
here is a better understanding of exactly which commands this change
will affect and some thought about how plausible it is that someone
could be depending on those tags.

In particular, it seems to me that it's rather unlikely that anyone is
depending on the command tag from an operation like CREATE TABLE AS or
SELECT INTO, because isn't it always going to be SELECT?

Furthermore, if we are going to ever change this in an incompatible
way that may break clients, isn't 9.0 exactly the right time to do
that?  If that doesn't scream "big changes coming, proceed with
caution", I don't know what would.

...Robert