Skip site navigation (1) Skip section navigation (2)

Re: plpython3

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, James Pye <lists(at)jwp(dot)name>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: plpython3
Date: 2010-01-13 19:15:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Jan 13, 2010 at 1:16 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> My argument would be now, what is the benefit of the James Pye version
>> over our version. James can you illustrate succinctly why we should be
>> supporting a new version?
>> If there is, I am still all for it, but I am a python bigot.
> Yeah, it's just my viewpoint that we don't want 2 python procedural
> languages in core.  One should be in core, and one should go on
> pgFoundry/PGAN.  Which ever one is "better" by some clear definition
> should go in core.

That was my thinking also.  There are a couple of reasons to think
that throwing over the current implementation for an new one may not
be the right thing to do.

1. It's not just a rewrite, it's an incompatible rewrite that will
present significant user-visible behavioral differences.  So replacing
the current implementation wholesale would produce massive breakage
for anyone actually using PL/python in production.

2. Peter Eisentraut, who has put significant time into improving
PL/python for this release (see the commit logs), and who is the ONLY
committer to work on improving PL/python for this release, has made it
clear that he prefers the current implementation.

Given these two facts, it's hard for me to see how we could decide to
REMOVE the current implementation and replace it with the new one.  So
the most we could do is maintain them side by side, and then you have
to ask, why?  It will actually be much easier for James Pye to
maintain his code outside core, and if it turns out to be popular and
people come back to us and say "hey, why isn't this the default?" then
we can revisit the issue.  Sure, his code won't get as much exposure
that way, but it's been posted to the mailing list several times now
over a period of 8 months and nobody has said "oh, wow, this is
great".  The most we've gotten is several versions of this exchange:

Somebody: We should really consider this code, the current code isn't very good.
Peter: What's wrong with it?
Somebody: <describes some problem, usually fairly vaguely>
Peter: Why can't we fix that in the existing code base?
<thread ends>

I'm not saying a complete rewrite isn't the way to go - I'm just
saying that there isn't much evidence at this point that it's really
necessary, and I don't think we want to maintain two copies of
PL/python unless we're really sure that the new implementation is an


In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2010-01-13 19:20:29
Subject: Re: Hot Standby and query cancel
Previous:From: Boszormenyi ZoltanDate: 2010-01-13 19:12:33
Subject: Re: lock_timeout GUC patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group