Thread: Re: [COMMITTERS] pgsql: Allow PL/python to return composite types and result sets Sven

momjian@postgresql.org (Bruce Momjian) writes:
> Log Message:
> -----------
> Allow PL/python to return composite types and result sets

Yah know, I've been asking for weeks for someone familiar with plpython
to review that.  Have our review standards just dropped to "commit it
and see what happens?"
        regards, tom lane


Re: [COMMITTERS] pgsql: Allow PL/python to return composite

From
Bruce Momjian
Date:
Tom Lane wrote:
> momjian@postgresql.org (Bruce Momjian) writes:
> > Log Message:
> > -----------
> > Allow PL/python to return composite types and result sets
> 
> Yah know, I've been asking for weeks for someone familiar with plpython
> to review that.  Have our review standards just dropped to "commit it
> and see what happens?"

Yes, they have.  I don't have the patience to track it anymore.  If I
revert it, someone else is going to have to deal with it.  If no one has
jumped to review it at this stage, we just have to throw the patch away.

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


Re: [COMMITTERS] pgsql: Allow PL/python to return

From
Hannu Krosing
Date:
Ühel kenal päeval, L, 2006-09-02 kell 10:25, kirjutas Tom Lane:
> momjian@postgresql.org (Bruce Momjian) writes:
> > Log Message:
> > -----------
> > Allow PL/python to return composite types and result sets
> 
> Yah know, I've been asking for weeks for someone familiar with plpython
> to review that. 

There was some review, which revealed one questionable practice (not
checking for NULL return) which was fixed AFAIK.

Do you have anyone specific in mind who should also do the review ?

>  Have our review standards just dropped to "commit it and see what happens?"



-- 
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me:  callto:hkrosing
Get Skype for free:  http://www.skype.com

NOTICE: This communication contains privileged or other confidential
information. If you have received it in error, please advise the sender
by reply email and immediately delete the message and any attachments
without copying or disclosing the contents.



Re: [COMMITTERS] pgsql: Allow PL/python to return

From
Tom Lane
Date:
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


Re: [COMMITTERS] pgsql: Allow PL/python to return

From
Bruce Momjian
Date:
Tom Lane wrote:
> 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.

You and me both, buddy.  I often feel like I am not fully capable of
doing many of the tasks I do, but because no one else wants to do it, I
make the best of it and hope others will help out if problems arise.

You would think our system of applying and getting feedback would have
failed to produce quality software long ago, but it hasn't.  ;-)  One
good thing is that people love a puzzle, so problems seems to get
fleshed out pretty quickly.

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


Re: [COMMITTERS] pgsql: Allow PL/python to return

From
Hannu Krosing
Date:
Ühel kenal päeval, L, 2006-09-02 kell 11:20, kirjutas Tom Lane:
> 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. 

I think/hope we (Skype) gave that task to Sven Suursoho, at least for a
few years from now. But it would really be good, if we had at least 2
people who could review each others code.

> 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.)

Yes, named params should be supported now.

Well, I guess Sven could take a look at IN/OUT params as well and see
what can be done.

I also have got some complaints about plpython not being able to accept
records as  input parameters. 

And IIRC there were some issues with returning BYTEA type thanks to
python producing hex representation for unprintable chars and postgresql
expecting octal, and requiring dual escaping for \0 and \\. I then
resolved it with a special python class Bytea() with its onn __str__ and
__repr__ methods, but it would be better if language handler could do it
directly.

> 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.

We are actually using it (or rather backport to 8.0/8.1) on our test
machines without seeing any bugs for some time already, even before the
NULL-return checking went in.

Otoh, we are not specifically looking for bugs on plpython there, but
rather if our own code runs without errors.

-- 
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me:  callto:hkrosing
Get Skype for free:  http://www.skype.com