Re: [COMMITTERS] pgsql: Allow PL/python to return - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [COMMITTERS] pgsql: Allow PL/python to return
Date
Msg-id 3066.1157210407@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Allow PL/python to return  (Hannu Krosing <hannu@skype.net>)
Responses Re: [COMMITTERS] pgsql: Allow PL/python to return  (Bruce Momjian <bruce@momjian.us>)
Re: [COMMITTERS] pgsql: Allow PL/python to return  (Hannu Krosing <hannu@skype.net>)
List pgsql-hackers
Hannu Krosing <hannu@skype.net> writes:
> Do you have anyone specific in mind who should also do the review ?

I went through the commit log for plpython.c to see who'd be a likely
prospect, and was dismayed to realize that basically no one has done
any serious work on it since the original author disappeared about four
years back :-(.  There are a whole lot of commits that are
search-and-replace by-blow from unrelated backend changes, and a couple
of people have fixed isolated bugs, but I'm not sure we have anyone who
would claim to understand the module as a whole.  Scary.

I guess what I'm wishing for is someone to adopt ownership of plpython
and invest the effort to get up to speed on the whole thing.  It's
certainly well behind the curve on such things as support of IN/OUT
parameters.  (I was about to say named parameters as well, but on second
look it looks like this commit just did something about that.)

Anyway, I can't say whether or not there's anything wrong with this
patch --- it may well be just fine.  What's bugging me is that we don't
seem to have any way to find out except wait for bug reports.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Greg Sabino Mullane"
Date:
Subject: Postgres tracking - the pgtrack project
Next
From: Tom Lane
Date:
Subject: Re: Getting a move on for 8.2 beta