From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alexey Grishchenko <agrishchenko(at)pivotal(dot)io> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Endless loop calling PL/Python set returning functions |
Date: | 2016-03-10 16:33:13 |
Message-ID: | 4805.1457627593@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alexey Grishchenko <agrishchenko(at)pivotal(dot)io> writes:
> One scenario when the problem occurs, is when you are calling the same
> set-returning function in a single query twice. This way they share the
> same "globals" which is not a bad thing, but when one function finishes
> execution and deallocates input parameter's global, the second will fail
> trying to do the same. I included the fix for this problem in my patch
> The second scenario when the problem occurs is when you want to call the
> same PL/Python function in recursion. For example, this code will not work:
Right, the recursion case is what's not being covered by this patch.
I would rather have a single patch that deals with both of those cases,
perhaps by *not* sharing the same dictionary across calls. I think
what you've done here is not so much a fix as a band-aid. In fact,
it doesn't even really fix the problem for the two-calls-per-query
case does it? It'll work if the first execution of the SRF is run to
completion before starting the second one, but not if the two executions
are interleaved. I believe you can test that type of scenario with
something like
select set_returning_function_1(...), set_returning_function_2(...);
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2016-03-10 16:33:49 | Re: Add generate_series(date,date) and generate_series(date,date,integer) |
Previous Message | Michael Paquier | 2016-03-10 16:30:51 | Re: Add generate_series(date,date) and generate_series(date,date,integer) |