From: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> |
---|---|
To: | Jan Urbański <wulczer(at)wulczer(dot)org> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: REVIEW: PL/Python table functions |
Date: | 2011-02-09 03:22:38 |
Message-ID: | AANLkTikJrDoPJcuTX-tfU=PX1cLGE7Qs_G1w9mivtj0_@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2011/2/9 Jan Urbański <wulczer(at)wulczer(dot)org>:
> 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 :)
I tested it on the issue above and things around trigger, and looked
good to me. Although I'm not sure if I understand the code overall,
but the modification where I'm unclear seems covered by the regression
tests.
I mark this "Ready for Committer."
Regards,
--
Hitoshi Harada
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-02-09 03:25:30 | Re: Extensions versus pg_upgrade |
Previous Message | Robert Haas | 2011-02-09 03:04:56 | Re: Extensions versus pg_upgrade |