Re: plpython is broken for recursive use

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: plpython is broken for recursive use
Date: 2015-10-17 02:03:32
Message-ID: 17326.1445047412@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> This seems like a very Rube-Goldbergian way of setting up a local
> namespace for the user-defined code. I think perhaps what we should do
> is:

> 1. Compile the user-supplied code directly into a code object, without
> wrapping it in a "def". (Hence, PLy_procedure_munge_source goes away
> entirely, which would be nice.) Forget about generating a code object
> containing a call, too.

After further study, it appears this approach won't work because it
breaks "yield" --- AFAICT, Python only allows "yield" inside a "def".

At this point I think what we need is to find a way of passing the
function parameters honestly, that is, as actual parameters in the
manufactured call. I've not looked into how that might be done.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2015-10-17 02:11:05 Re: [PATCH v3] GSSAPI encryption support
Previous Message Tom Lane 2015-10-17 01:51:52 Re: Foreign join pushdown vs EvalPlanQual