Re: REVIEW: PL/Python table functions - Mailing list pgsql-hackers

From Jan Urbański
Subject Re: REVIEW: PL/Python table functions
Date
Msg-id 4D51C51A.4030400@wulczer.org
Whole thread Raw
In response to Re: REVIEW: PL/Python table functions  (Hitoshi Harada <umi.tanuki@gmail.com>)
Responses Re: REVIEW: PL/Python table functions
Re: REVIEW: PL/Python table functions
List pgsql-hackers
On 07/02/11 06:10, Hitoshi Harada wrote:
> 2011/2/7 Jan Urbański <wulczer@wulczer.org>:
>> On 04/02/11 16:26, Hitoshi Harada wrote:
>>> 2011/1/28 Jan Urbański <wulczer@wulczer.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,
Jan

Attachment

pgsql-hackers by date:

Previous
From: Thom Brown
Date:
Subject: Re: Per-column collation, the finale
Next
From: Tom Lane
Date:
Subject: Re: Extensions versus pg_upgrade