Re: REVIEW: PL/Python table functions

From: Jan Urbański <wulczer(at)wulczer(dot)org>
To: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: REVIEW: PL/Python table functions
Date: 2011-02-08 22:35:06
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 07/02/11 06:10, Hitoshi Harada wrote:
> 2011/2/7 Jan Urbański <wulczer(at)wulczer(dot)org>:
>> On 04/02/11 16:26, Hitoshi Harada wrote:
>>> 2011/1/28 Jan Urbański <wulczer(at)wulczer(dot)org>:
>>>> On 27/01/11 00:41, Jan Urbański wrote:
>>>>> I'm also attaching an updated version that should apply on top of my
>>>>> github refactor branch (or incrementally over the new set of refactor
>>>>> patches that I will post shortly to the refactor thread).
>>>> Attached is a patch for master, as the refactorings have already been
>>>> merged.
>>> Sorry, but could you update your patch? Patching it against HEAD today
>>> makes rej.
>> Sure, here's an updated patch.
> Thanks,
> I revisited the problem of typeinfo cache, and I guess this is not
> what you want;
> [problems, now reflected in new regression tests]
> The PL/pgSQL case you pointed earlier is consistent because it fetches
> the values positionally. The column name is only an on-demand
> labeling. However, for mapping dict of python into the table row
> should always map it by key. At least the function author (including
> me :P) expects it.

Yes, you're right. I tried to be too cute checking if the arguments are
binary coercible to the fit the new record description. This time I'm
just checking if the record descriptor changed at all, and if so
recaching the I/O funcs.

I hope this version does the right thing, while still avoiding the
performance hit of looking up I/O funcs every time a row is returned.
Actually, PL/Perl *does* look up the I/O funcs every time, so in the
worst case I can just drop this optimisation. But let's hope I got it
right this time :)

Thanks again for the review,

Attachment Content-Type Size
plpython-table-functions.patch text/x-patch 35.6 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-02-08 22:41:01 Re: Extensions versus pg_upgrade
Previous Message Thom Brown 2011-02-08 22:17:59 Re: Per-column collation, the finale