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

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

From: Hannu Krosing <hannu(at)skype(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org,Sven Suursoho <sven(dot)suursoho(at)skype(dot)net>,Asko Oja <asko(dot)oja(at)skype(dot)net>
Subject: Re: [COMMITTERS] pgsql: Allow PL/python to return
Date: 2006-09-02 16:30:16
Message-ID: 1157214616.3799.20.camel@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-committerspgsql-hackers
Ühel kenal päeval, L, 2006-09-02 kell 11:20, kirjutas Tom Lane:
> Hannu Krosing <hannu(at)skype(dot)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

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

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-09-02 16:39:16
Subject: Re: [COMMITTERS] pgsql: Add new variable "server_version_num", which is almost the same
Previous:From: Lukas Kahwe SmithDate: 2006-09-02 16:28:55
Subject: Re: Getting a move on for 8.2 beta

pgsql-committers by date

Next:From: Tom LaneDate: 2006-09-02 16:39:16
Subject: Re: [COMMITTERS] pgsql: Add new variable "server_version_num", which is almost the same
Previous:From: Bruce MomjianDate: 2006-09-02 16:07:15
Subject: Re: [COMMITTERS] pgsql: Suppress some NOTICE

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