Thread: Re: [COMMITTERS] pgsql: Allow PL/python to return composite types and result sets Sven
Re: [COMMITTERS] pgsql: Allow PL/python to return composite types and result sets Sven
From
Tom Lane
Date:
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
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. +
Ü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.
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
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. +
Ü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