From: | Jan Urbański <wulczer(at)wulczer(dot)org> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pl/python do not delete function arguments |
Date: | 2011-02-15 08:58:15 |
Message-ID: | 1297760295.3948.2.camel@Nokia-N900-42-11 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
----- Original message -----
> On mån, 2011-02-14 at 22:22 +0100, Jan Urbański wrote:
> > The problem is that every *second* call to the function fails,
> > regardless of the number. The first execution succeeds, but then
> > PLy_delete_args deletes the argument from the globals, and when the
> > next execution tries to fetch "n" from it, it raises a KeyError.
>
> This isn't quite right either, because it obviously depends on the
> recursion somehow. So in
>
> SELECT recursion_test(5);
> SELECT recursion_test(4);
>
> it is the first recursive invocation of the (4) call that fails. If you
> just do
>
> SELECT recursion_test(1);
> SELECT recursion_test(1);
> SELECT recursion_test(1);
>
> nothing fails. (We'd have noticed that sooner, obviously. ;-) )
Isn't that because with 1 there is no recursion, i.e. plpy.execute never gets called from Python?
> But in
>
> SELECT recursion_test(1);
> SELECT recursion_test(4);
> SELECT recursion_test(1);
>
> it's the last (1) call, which is not recursive, that fails.
Because the invocation that actually recurses sets up the scene for failure.
Jan
From | Date | Subject | |
---|---|---|---|
Next Message | Itagaki Takahiro | 2011-02-15 09:31:19 | Re: multiset patch review |
Previous Message | Heikki Linnakangas | 2011-02-15 08:38:37 | Re: pageinspect's infomask and infomask2 as smallint |