On 10/16/2015 10:03 PM, Tom Lane wrote:
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,
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 a
I wrote:
> Anyway, the real problem here is the decision to pass procedure arguments
> by assigning them to keys in the global dict. That is just brain-dead,
> both because it means that recursive calls can't possibly work and because
> it creates the bizarre scoping behavior mentioned in
> http:/
Andrew Dunstan writes:
> On 10/15/2015 05:16 PM, Josh Berkus wrote:
>> On 10/15/2015 01:10 PM, Tom Lane wrote:
>>> I think this means that we should get rid of proc->globals and instead
>>> manufacture a new globals dict locally in each call to PLy_exec_function
>>> or PLy_exec_trigger.
>> Don't
On 10/15/2015 02:16 PM, Josh Berkus wrote:
On 10/15/2015 01:10 PM, Tom Lane wrote:
I think this means that we should get rid of proc->globals and instead
manufacture a new globals dict locally in each call to PLy_exec_function
or PLy_exec_trigger. For SETOF functions it would be necessary to ke
On 10/15/2015 05:16 PM, Josh Berkus wrote:
On 10/15/2015 01:10 PM, Tom Lane wrote:
I think this means that we should get rid of proc->globals and instead
manufacture a new globals dict locally in each call to PLy_exec_function
or PLy_exec_trigger. For SETOF functions it would be necessary to
On 10/15/2015 01:10 PM, Tom Lane wrote:
> I think this means that we should get rid of proc->globals and instead
> manufacture a new globals dict locally in each call to PLy_exec_function
> or PLy_exec_trigger. For SETOF functions it would be necessary to keep
> the globals dict reference somewher
I looked into bug #13683,
http://www.postgresql.org/message-id/20151015135804.3019.31...@wrigleys.postgresql.org
It looks to me like plpython basically doesn't work at all for re-entrant
calls to plpython functions, because all executions of a given function
share the same "globals" dict, which do