Re: REVIEW: PL/Python table functions

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,
Jan