2011-12-18 14:14:16 -05:00
|
|
|
/*
|
|
|
|
|
* src/pl/plpython/plpy_procedure.h
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef PLPY_PROCEDURE_H
|
|
|
|
|
#define PLPY_PROCEDURE_H
|
|
|
|
|
|
|
|
|
|
#include "plpy_typeio.h"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
extern void init_procedure_caches(void);
|
|
|
|
|
|
|
|
|
|
|
Fix PL/Python for recursion and interleaved set-returning functions.
PL/Python failed if a PL/Python function was invoked recursively via SPI,
since arguments are passed to the function in its global dictionary
(a horrible decision that's far too ancient to undo) and it would delete
those dictionary entries on function exit, leaving the outer recursion
level(s) without any arguments. Not deleting them would be little better,
since the outer levels would then see the innermost level's arguments.
Since PL/Python uses ValuePerCall mode for evaluating set-returning
functions, it's possible for multiple executions of the same SRF to be
interleaved within a query. PL/Python failed in such a case, because
it stored only one iterator per function, directly in the function's
PLyProcedure struct. Moreover, one interleaved instance of the SRF
would see argument values that should belong to another.
Hence, invent code for saving and restoring the argument entries. To fix
the recursion case, we only need to save at recursive entry and restore
at recursive exit, so the overhead in non-recursive cases is negligible.
To fix the SRF case, we have to save when suspending a SRF and restore
when resuming it, which is potentially not negligible; but fortunately
this is mostly a matter of manipulating Python object refcounts and
should not involve much physical data copying.
Also, store the Python iterator and saved argument values in a structure
associated with the SRF call site rather than the function itself. This
requires adding a memory context deletion callback to ensure that the SRF
state is cleaned up if the calling query exits before running the SRF to
completion. Without that we'd leak a refcount to the iterator object in
such a case, resulting in session-lifespan memory leakage. (In the
pre-existing code, there was no memory leak because there was only one
iterator pointer, but what would happen is that the previous iterator
would be resumed by the next query attempting to use the SRF. Hardly the
semantics we want.)
We can buy back some of whatever overhead we've added by getting rid of
PLy_function_delete_args(), which seems a useless activity: there is no
need to delete argument entries from the global dictionary on exit,
since the next time anyone would see the global dict is on the next
fresh call of the PL/Python function, at which time we'd overwrite those
entries with new arg values anyway.
Also clean up some really ugly coding in the SRF implementation, including
such gems as returning directly out of a PG_TRY block. (The only reason
that failed to crash hard was that all existing call sites immediately
exited their own PG_TRY blocks, popping the dangling longjmp pointer before
there was any chance of it being used.)
In principle this is a bug fix; but it seems a bit too invasive relative to
its value for a back-patch, and besides the fix depends on memory context
callbacks so it could not go back further than 9.5 anyway.
Alexey Grishchenko and Tom Lane
2016-04-05 14:50:30 -04:00
|
|
|
/* saved arguments for outer recursion level or set-returning function */
|
|
|
|
|
typedef struct PLySavedArgs
|
|
|
|
|
{
|
|
|
|
|
struct PLySavedArgs *next; /* linked-list pointer */
|
|
|
|
|
PyObject *args; /* "args" element of globals dict */
|
2024-05-07 18:15:00 -04:00
|
|
|
PyObject *td; /* "TD" element of globals dict, if trigger */
|
Fix PL/Python for recursion and interleaved set-returning functions.
PL/Python failed if a PL/Python function was invoked recursively via SPI,
since arguments are passed to the function in its global dictionary
(a horrible decision that's far too ancient to undo) and it would delete
those dictionary entries on function exit, leaving the outer recursion
level(s) without any arguments. Not deleting them would be little better,
since the outer levels would then see the innermost level's arguments.
Since PL/Python uses ValuePerCall mode for evaluating set-returning
functions, it's possible for multiple executions of the same SRF to be
interleaved within a query. PL/Python failed in such a case, because
it stored only one iterator per function, directly in the function's
PLyProcedure struct. Moreover, one interleaved instance of the SRF
would see argument values that should belong to another.
Hence, invent code for saving and restoring the argument entries. To fix
the recursion case, we only need to save at recursive entry and restore
at recursive exit, so the overhead in non-recursive cases is negligible.
To fix the SRF case, we have to save when suspending a SRF and restore
when resuming it, which is potentially not negligible; but fortunately
this is mostly a matter of manipulating Python object refcounts and
should not involve much physical data copying.
Also, store the Python iterator and saved argument values in a structure
associated with the SRF call site rather than the function itself. This
requires adding a memory context deletion callback to ensure that the SRF
state is cleaned up if the calling query exits before running the SRF to
completion. Without that we'd leak a refcount to the iterator object in
such a case, resulting in session-lifespan memory leakage. (In the
pre-existing code, there was no memory leak because there was only one
iterator pointer, but what would happen is that the previous iterator
would be resumed by the next query attempting to use the SRF. Hardly the
semantics we want.)
We can buy back some of whatever overhead we've added by getting rid of
PLy_function_delete_args(), which seems a useless activity: there is no
need to delete argument entries from the global dictionary on exit,
since the next time anyone would see the global dict is on the next
fresh call of the PL/Python function, at which time we'd overwrite those
entries with new arg values anyway.
Also clean up some really ugly coding in the SRF implementation, including
such gems as returning directly out of a PG_TRY block. (The only reason
that failed to crash hard was that all existing call sites immediately
exited their own PG_TRY blocks, popping the dangling longjmp pointer before
there was any chance of it being used.)
In principle this is a bug fix; but it seems a bit too invasive relative to
its value for a back-patch, and besides the fix depends on memory context
callbacks so it could not go back further than 9.5 anyway.
Alexey Grishchenko and Tom Lane
2016-04-05 14:50:30 -04:00
|
|
|
int nargs; /* length of namedargs array */
|
|
|
|
|
PyObject *namedargs[FLEXIBLE_ARRAY_MEMBER]; /* named args */
|
|
|
|
|
} PLySavedArgs;
|
|
|
|
|
|
2011-12-18 14:14:16 -05:00
|
|
|
/* cached procedure data */
|
|
|
|
|
typedef struct PLyProcedure
|
|
|
|
|
{
|
2015-11-05 13:52:30 -05:00
|
|
|
MemoryContext mcxt; /* context holding this PLyProcedure and its
|
|
|
|
|
* subsidiary data */
|
2011-12-18 14:14:16 -05:00
|
|
|
char *proname; /* SQL name of procedure */
|
|
|
|
|
char *pyname; /* Python name of procedure */
|
|
|
|
|
TransactionId fn_xmin;
|
|
|
|
|
ItemPointerData fn_tid;
|
|
|
|
|
bool fn_readonly;
|
2017-11-30 08:46:13 -05:00
|
|
|
bool is_setof; /* true, if function returns result set */
|
|
|
|
|
bool is_procedure;
|
2024-05-07 18:15:00 -04:00
|
|
|
bool is_trigger; /* called as trigger? */
|
Make PL/Python handle domain-type conversions correctly.
Fix PL/Python so that it can handle domains over composite, and so that
it enforces domain constraints correctly in other cases that were not
always done properly before. Notably, it didn't do arrays of domains
right (oversight in commit c12d570fa), and it failed to enforce domain
constraints when returning a composite type containing a domain field,
and if a transform function is being used for a domain's base type then
it failed to enforce domain constraints on the result. Also, in many
places it missed checking domain constraints on null values, because
the plpy_typeio code simply wasn't called for Py_None.
Rather than try to band-aid these problems, I made a significant
refactoring of the plpy_typeio logic. The existing design of recursing
for array and composite members is extended to also treat domains as
containers requiring recursion, and the APIs for the module are cleaned
up and simplified.
The patch also modifies plpy_typeio to rely on the typcache more than
it did before (which was pretty much not at all). This reduces the
need for repetitive lookups, and lets us get rid of an ad-hoc scheme
for detecting changes in composite types. I added a couple of small
features to typcache to help with that.
Although some of this is fixing bugs that long predate v11, I don't
think we should risk a back-patch: it's a significant amount of code
churn, and there've been no complaints from the field about the bugs.
Tom Lane, reviewed by Anthony Bykov
Discussion: https://postgr.es/m/24449.1509393613@sss.pgh.pa.us
2017-11-16 16:22:57 -05:00
|
|
|
PLyObToDatum result; /* Function result output conversion info */
|
|
|
|
|
PLyDatumToOb result_in; /* For converting input tuples in a trigger */
|
2011-12-18 14:14:16 -05:00
|
|
|
char *src; /* textual procedure code, after mangling */
|
|
|
|
|
char **argnames; /* Argument names */
|
Make PL/Python handle domain-type conversions correctly.
Fix PL/Python so that it can handle domains over composite, and so that
it enforces domain constraints correctly in other cases that were not
always done properly before. Notably, it didn't do arrays of domains
right (oversight in commit c12d570fa), and it failed to enforce domain
constraints when returning a composite type containing a domain field,
and if a transform function is being used for a domain's base type then
it failed to enforce domain constraints on the result. Also, in many
places it missed checking domain constraints on null values, because
the plpy_typeio code simply wasn't called for Py_None.
Rather than try to band-aid these problems, I made a significant
refactoring of the plpy_typeio logic. The existing design of recursing
for array and composite members is extended to also treat domains as
containers requiring recursion, and the APIs for the module are cleaned
up and simplified.
The patch also modifies plpy_typeio to rely on the typcache more than
it did before (which was pretty much not at all). This reduces the
need for repetitive lookups, and lets us get rid of an ad-hoc scheme
for detecting changes in composite types. I added a couple of small
features to typcache to help with that.
Although some of this is fixing bugs that long predate v11, I don't
think we should risk a back-patch: it's a significant amount of code
churn, and there've been no complaints from the field about the bugs.
Tom Lane, reviewed by Anthony Bykov
Discussion: https://postgr.es/m/24449.1509393613@sss.pgh.pa.us
2017-11-16 16:22:57 -05:00
|
|
|
PLyDatumToOb *args; /* Argument input conversion info */
|
|
|
|
|
int nargs; /* Number of elements in above arrays */
|
2015-04-26 10:33:14 -04:00
|
|
|
Oid langid; /* OID of plpython pg_language entry */
|
|
|
|
|
List *trftypes; /* OID list of transform types */
|
2011-12-18 14:14:16 -05:00
|
|
|
PyObject *code; /* compiled procedure code */
|
|
|
|
|
PyObject *statics; /* data saved across calls, local scope */
|
|
|
|
|
PyObject *globals; /* data saved across calls, global scope */
|
Fix PL/Python for recursion and interleaved set-returning functions.
PL/Python failed if a PL/Python function was invoked recursively via SPI,
since arguments are passed to the function in its global dictionary
(a horrible decision that's far too ancient to undo) and it would delete
those dictionary entries on function exit, leaving the outer recursion
level(s) without any arguments. Not deleting them would be little better,
since the outer levels would then see the innermost level's arguments.
Since PL/Python uses ValuePerCall mode for evaluating set-returning
functions, it's possible for multiple executions of the same SRF to be
interleaved within a query. PL/Python failed in such a case, because
it stored only one iterator per function, directly in the function's
PLyProcedure struct. Moreover, one interleaved instance of the SRF
would see argument values that should belong to another.
Hence, invent code for saving and restoring the argument entries. To fix
the recursion case, we only need to save at recursive entry and restore
at recursive exit, so the overhead in non-recursive cases is negligible.
To fix the SRF case, we have to save when suspending a SRF and restore
when resuming it, which is potentially not negligible; but fortunately
this is mostly a matter of manipulating Python object refcounts and
should not involve much physical data copying.
Also, store the Python iterator and saved argument values in a structure
associated with the SRF call site rather than the function itself. This
requires adding a memory context deletion callback to ensure that the SRF
state is cleaned up if the calling query exits before running the SRF to
completion. Without that we'd leak a refcount to the iterator object in
such a case, resulting in session-lifespan memory leakage. (In the
pre-existing code, there was no memory leak because there was only one
iterator pointer, but what would happen is that the previous iterator
would be resumed by the next query attempting to use the SRF. Hardly the
semantics we want.)
We can buy back some of whatever overhead we've added by getting rid of
PLy_function_delete_args(), which seems a useless activity: there is no
need to delete argument entries from the global dictionary on exit,
since the next time anyone would see the global dict is on the next
fresh call of the PL/Python function, at which time we'd overwrite those
entries with new arg values anyway.
Also clean up some really ugly coding in the SRF implementation, including
such gems as returning directly out of a PG_TRY block. (The only reason
that failed to crash hard was that all existing call sites immediately
exited their own PG_TRY blocks, popping the dangling longjmp pointer before
there was any chance of it being used.)
In principle this is a bug fix; but it seems a bit too invasive relative to
its value for a back-patch, and besides the fix depends on memory context
callbacks so it could not go back further than 9.5 anyway.
Alexey Grishchenko and Tom Lane
2016-04-05 14:50:30 -04:00
|
|
|
long calldepth; /* depth of recursive calls of function */
|
|
|
|
|
PLySavedArgs *argstack; /* stack of outer-level call arguments */
|
2011-12-18 14:14:16 -05:00
|
|
|
} PLyProcedure;
|
|
|
|
|
|
2013-01-25 16:58:55 -05:00
|
|
|
/* the procedure cache key */
|
|
|
|
|
typedef struct PLyProcedureKey
|
|
|
|
|
{
|
|
|
|
|
Oid fn_oid; /* function OID */
|
|
|
|
|
Oid fn_rel; /* triggered-on relation or InvalidOid */
|
|
|
|
|
} PLyProcedureKey;
|
|
|
|
|
|
2011-12-18 14:14:16 -05:00
|
|
|
/* the procedure cache entry */
|
|
|
|
|
typedef struct PLyProcedureEntry
|
|
|
|
|
{
|
2013-01-25 16:58:55 -05:00
|
|
|
PLyProcedureKey key; /* hash key */
|
2011-12-18 14:14:16 -05:00
|
|
|
PLyProcedure *proc;
|
|
|
|
|
} PLyProcedureEntry;
|
|
|
|
|
|
|
|
|
|
/* PLyProcedure manipulation */
|
2011-12-29 15:55:49 -05:00
|
|
|
extern char *PLy_procedure_name(PLyProcedure *proc);
|
2013-01-25 16:58:55 -05:00
|
|
|
extern PLyProcedure *PLy_procedure_get(Oid fn_oid, Oid fn_rel, bool is_trigger);
|
2011-12-29 15:55:49 -05:00
|
|
|
extern void PLy_procedure_compile(PLyProcedure *proc, const char *src);
|
|
|
|
|
extern void PLy_procedure_delete(PLyProcedure *proc);
|
2011-12-18 14:14:16 -05:00
|
|
|
|
|
|
|
|
#endif /* PLPY_PROCEDURE_H */
|
