Re: [HACKERS] plpython is broken for recursive use

2015-10-17 Thread Andrew Dunstan
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".

Re: [HACKERS] plpython is broken for recursive use

2015-10-16 Thread Tom Lane
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 >

Re: [HACKERS] plpython is broken for recursive use

2015-10-16 Thread Tom Lane
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

Re: [HACKERS] plpython is broken for recursive use

2015-10-15 Thread Tom Lane
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

Re: [HACKERS] plpython is broken for recursive use

2015-10-15 Thread Josh Berkus
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

[HACKERS] plpython is broken for recursive use

2015-10-15 Thread Tom Lane
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

Re: [HACKERS] plpython is broken for recursive use

2015-10-15 Thread Joshua D. Drake
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

Re: [HACKERS] plpython is broken for recursive use

2015-10-15 Thread Andrew Dunstan
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