2011-12-18 20:14:16 +01:00
|
|
|
/*
|
|
|
|
* Python procedure manipulation for plpython
|
|
|
|
*
|
|
|
|
* src/pl/plpython/plpy_procedure.c
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "postgres.h"
|
|
|
|
|
2012-08-30 22:15:44 +02:00
|
|
|
#include "access/htup_details.h"
|
2011-12-18 20:14:16 +01:00
|
|
|
#include "access/transam.h"
|
|
|
|
#include "catalog/pg_proc.h"
|
|
|
|
#include "catalog/pg_type.h"
|
2024-03-13 15:07:00 +01:00
|
|
|
#include "funcapi.h"
|
2019-11-25 03:38:57 +01:00
|
|
|
#include "plpy_elog.h"
|
|
|
|
#include "plpy_main.h"
|
|
|
|
#include "plpy_procedure.h"
|
|
|
|
#include "plpython.h"
|
2011-12-18 20:14:16 +01:00
|
|
|
#include "utils/builtins.h"
|
|
|
|
#include "utils/hsearch.h"
|
2015-04-26 16:33:14 +02:00
|
|
|
#include "utils/inval.h"
|
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 22:22:57 +01:00
|
|
|
#include "utils/lsyscache.h"
|
2015-04-26 16:33:14 +02:00
|
|
|
#include "utils/memutils.h"
|
2011-12-18 20:14:16 +01:00
|
|
|
#include "utils/syscache.h"
|
|
|
|
|
|
|
|
static HTAB *PLy_procedure_cache = NULL;
|
|
|
|
|
2011-12-29 21:55:49 +01:00
|
|
|
static PLyProcedure *PLy_procedure_create(HeapTuple procTup, Oid fn_oid, bool is_trigger);
|
|
|
|
static bool PLy_procedure_valid(PLyProcedure *proc, HeapTuple procTup);
|
|
|
|
static char *PLy_procedure_munge_source(const char *name, const char *src);
|
2011-12-18 20:14:16 +01:00
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
init_procedure_caches(void)
|
|
|
|
{
|
|
|
|
HASHCTL hash_ctl;
|
|
|
|
|
2013-01-25 22:58:55 +01:00
|
|
|
hash_ctl.keysize = sizeof(PLyProcedureKey);
|
2011-12-18 20:14:16 +01:00
|
|
|
hash_ctl.entrysize = sizeof(PLyProcedureEntry);
|
|
|
|
PLy_procedure_cache = hash_create("PL/Python procedures", 32, &hash_ctl,
|
Improve hash_create's API for selecting simple-binary-key hash functions.
Previously, if you wanted anything besides C-string hash keys, you had to
specify a custom hashing function to hash_create(). Nearly all such
callers were specifying tag_hash or oid_hash; which is tedious, and rather
error-prone, since a caller could easily miss the opportunity to optimize
by using hash_uint32 when appropriate. Replace this with a design whereby
callers using simple binary-data keys just specify HASH_BLOBS and don't
need to mess with specific support functions. hash_create() itself will
take care of optimizing when the key size is four bytes.
This nets out saving a few hundred bytes of code space, and offers
a measurable performance improvement in tidbitmap.c (which was not
exploiting the opportunity to use hash_uint32 for its 4-byte keys).
There might be some wins elsewhere too, I didn't analyze closely.
In future we could look into offering a similar optimized hashing function
for 8-byte keys. Under this design that could be done in a centralized
and machine-independent fashion, whereas getting it right for keys of
platform-dependent sizes would've been notationally painful before.
For the moment, the old way still works fine, so as not to break source
code compatibility for loadable modules. Eventually we might want to
remove tag_hash and friends from the exported API altogether, since there's
no real need for them to be explicitly referenced from outside dynahash.c.
Teodor Sigaev and Tom Lane
2014-12-18 19:36:29 +01:00
|
|
|
HASH_ELEM | HASH_BLOBS);
|
2011-12-18 20:14:16 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2018-02-14 20:47:18 +01:00
|
|
|
* PLy_procedure_name: get the name of the specified procedure.
|
2011-12-18 20:14:16 +01:00
|
|
|
*
|
|
|
|
* NB: this returns the SQL name, not the internal Python procedure name
|
|
|
|
*/
|
|
|
|
char *
|
|
|
|
PLy_procedure_name(PLyProcedure *proc)
|
|
|
|
{
|
|
|
|
if (proc == NULL)
|
|
|
|
return "<unknown procedure>";
|
|
|
|
return proc->proname;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* PLy_procedure_get: returns a cached PLyProcedure, or creates, stores and
|
2013-01-25 22:58:55 +01:00
|
|
|
* returns a new PLyProcedure.
|
|
|
|
*
|
|
|
|
* fn_oid is the OID of the function requested
|
|
|
|
* fn_rel is InvalidOid or the relation this function triggers on
|
|
|
|
* is_trigger denotes whether the function is a trigger function
|
|
|
|
*
|
|
|
|
* The reason that both fn_rel and is_trigger need to be passed is that when
|
|
|
|
* trigger functions get validated we don't know which relation(s) they'll
|
|
|
|
* be used with, so no sensible fn_rel can be passed.
|
2011-12-18 20:14:16 +01:00
|
|
|
*/
|
|
|
|
PLyProcedure *
|
2013-01-25 22:58:55 +01:00
|
|
|
PLy_procedure_get(Oid fn_oid, Oid fn_rel, bool is_trigger)
|
2011-12-18 20:14:16 +01:00
|
|
|
{
|
2013-01-25 22:58:55 +01:00
|
|
|
bool use_cache = !(is_trigger && fn_rel == InvalidOid);
|
2011-12-18 20:14:16 +01:00
|
|
|
HeapTuple procTup;
|
2013-01-25 22:58:55 +01:00
|
|
|
PLyProcedureKey key;
|
|
|
|
PLyProcedureEntry *volatile entry = NULL;
|
|
|
|
PLyProcedure *volatile proc = NULL;
|
|
|
|
bool found = false;
|
2011-12-18 20:14:16 +01:00
|
|
|
|
|
|
|
procTup = SearchSysCache1(PROCOID, ObjectIdGetDatum(fn_oid));
|
|
|
|
if (!HeapTupleIsValid(procTup))
|
|
|
|
elog(ERROR, "cache lookup failed for function %u", fn_oid);
|
|
|
|
|
2013-01-25 22:58:55 +01:00
|
|
|
/*
|
|
|
|
* Look for the function in the cache, unless we don't have the necessary
|
|
|
|
* information (e.g. during validation). In that case we just don't cache
|
|
|
|
* anything.
|
|
|
|
*/
|
|
|
|
if (use_cache)
|
|
|
|
{
|
|
|
|
key.fn_oid = fn_oid;
|
|
|
|
key.fn_rel = fn_rel;
|
|
|
|
entry = hash_search(PLy_procedure_cache, &key, HASH_ENTER, &found);
|
|
|
|
proc = entry->proc;
|
|
|
|
}
|
2011-12-18 20:14:16 +01:00
|
|
|
|
|
|
|
PG_TRY();
|
|
|
|
{
|
|
|
|
if (!found)
|
|
|
|
{
|
2013-01-25 22:58:55 +01:00
|
|
|
/* Haven't found it, create a new procedure */
|
|
|
|
proc = PLy_procedure_create(procTup, fn_oid, is_trigger);
|
|
|
|
if (use_cache)
|
|
|
|
entry->proc = proc;
|
2011-12-18 20:14:16 +01:00
|
|
|
}
|
2013-01-25 22:58:55 +01:00
|
|
|
else if (!PLy_procedure_valid(proc, procTup))
|
2011-12-18 20:14:16 +01:00
|
|
|
{
|
|
|
|
/* Found it, but it's invalid, free and reuse the cache entry */
|
2015-11-05 19:52:30 +01:00
|
|
|
entry->proc = NULL;
|
|
|
|
if (proc)
|
|
|
|
PLy_procedure_delete(proc);
|
2013-01-25 22:58:55 +01:00
|
|
|
proc = PLy_procedure_create(procTup, fn_oid, is_trigger);
|
|
|
|
entry->proc = proc;
|
2011-12-18 20:14:16 +01:00
|
|
|
}
|
|
|
|
/* Found it and it's valid, it's fine to use it */
|
|
|
|
}
|
|
|
|
PG_CATCH();
|
|
|
|
{
|
2017-03-14 16:38:30 +01:00
|
|
|
/* Do not leave an uninitialized entry in the cache */
|
2013-01-25 22:58:55 +01:00
|
|
|
if (use_cache)
|
|
|
|
hash_search(PLy_procedure_cache, &key, HASH_REMOVE, NULL);
|
2011-12-18 20:14:16 +01:00
|
|
|
PG_RE_THROW();
|
|
|
|
}
|
|
|
|
PG_END_TRY();
|
|
|
|
|
|
|
|
ReleaseSysCache(procTup);
|
|
|
|
|
2013-01-25 22:58:55 +01:00
|
|
|
return proc;
|
2011-12-18 20:14:16 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Create a new PLyProcedure structure
|
|
|
|
*/
|
|
|
|
static PLyProcedure *
|
|
|
|
PLy_procedure_create(HeapTuple procTup, Oid fn_oid, bool is_trigger)
|
|
|
|
{
|
|
|
|
char procName[NAMEDATALEN + 256];
|
|
|
|
Form_pg_proc procStruct;
|
|
|
|
PLyProcedure *volatile proc;
|
2015-11-05 19:52:30 +01:00
|
|
|
MemoryContext cxt;
|
|
|
|
MemoryContext oldcxt;
|
|
|
|
int rv;
|
2016-02-17 03:08:15 +01:00
|
|
|
char *ptr;
|
2011-12-18 20:14:16 +01:00
|
|
|
|
|
|
|
procStruct = (Form_pg_proc) GETSTRUCT(procTup);
|
|
|
|
rv = snprintf(procName, sizeof(procName),
|
|
|
|
"__plpython_procedure_%s_%u",
|
|
|
|
NameStr(procStruct->proname),
|
|
|
|
fn_oid);
|
|
|
|
if (rv >= sizeof(procName) || rv < 0)
|
|
|
|
elog(ERROR, "procedure name would overrun buffer");
|
|
|
|
|
2016-02-17 03:08:15 +01:00
|
|
|
/* Replace any not-legal-in-Python-names characters with '_' */
|
|
|
|
for (ptr = procName; *ptr; ptr++)
|
|
|
|
{
|
|
|
|
if (!((*ptr >= 'A' && *ptr <= 'Z') ||
|
|
|
|
(*ptr >= 'a' && *ptr <= 'z') ||
|
|
|
|
(*ptr >= '0' && *ptr <= '9')))
|
|
|
|
*ptr = '_';
|
|
|
|
}
|
|
|
|
|
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 22:22:57 +01:00
|
|
|
/* Create long-lived context that all procedure info will live in */
|
Allow memory contexts to have both fixed and variable ident strings.
Originally, we treated memory context names as potentially variable in
all cases, and therefore always copied them into the context header.
Commit 9fa6f00b1 rethought this a little bit and invented a distinction
between fixed and variable names, skipping the copy step for the former.
But we can make things both simpler and more useful by instead allowing
there to be two parts to a context's identification, a fixed "name" and
an optional, variable "ident". The name supplied in the context create
call is now required to be a compile-time-constant string in all cases,
as it is never copied but just pointed to. The "ident" string, if
wanted, is supplied later. This is needed because typically we want
the ident to be stored inside the context so that it's cleaned up
automatically on context deletion; that means it has to be copied into
the context before we can set the pointer.
The cost of this approach is basically just an additional pointer field
in struct MemoryContextData, which isn't much overhead, and is bought
back entirely in the AllocSet case by not needing a headerSize field
anymore, since we no longer have to cope with variable header length.
In addition, we can simplify the internal interfaces for memory context
creation still further, saving a few cycles there. And it's no longer
true that a custom identifier disqualifies a context from participating
in aset.c's freelist scheme, so possibly there's some win on that end.
All the places that were using non-compile-time-constant context names
are adjusted to put the variable info into the "ident" instead. This
allows more effective identification of those contexts in many cases;
for example, subsidary contexts of relcache entries are now identified
by both type (e.g. "index info") and relname, where before you got only
one or the other. Contexts associated with PL function cache entries
are now identified more fully and uniformly, too.
I also arranged for plancache contexts to use the query source string
as their identifier. This is basically free for CachedPlanSources, as
they contained a copy of that string already. We pay an extra pstrdup
to do it for CachedPlans. That could perhaps be avoided, but it would
make things more fragile (since the CachedPlanSource is sometimes
destroyed first). I suspect future improvements in error reporting will
require CachedPlans to have a copy of that string anyway, so it's not
clear that it's worth moving mountains to avoid it now.
This also changes the APIs for context statistics routines so that the
context-specific routines no longer assume that output goes straight
to stderr, nor do they know all details of the output format. This
is useful immediately to reduce code duplication, and it also allows
for external code to do something with stats output that's different
from printing to stderr.
The reason for pushing this now rather than waiting for v12 is that
it rethinks some of the API changes made by commit 9fa6f00b1. Seems
better for extension authors to endure just one round of API changes
not two.
Discussion: https://postgr.es/m/CAB=Je-FdtmFZ9y9REHD7VsSrnCkiBhsA4mdsLKSPauwXtQBeNA@mail.gmail.com
2018-03-27 22:46:47 +02:00
|
|
|
cxt = AllocSetContextCreate(TopMemoryContext,
|
|
|
|
"PL/Python function",
|
|
|
|
ALLOCSET_DEFAULT_SIZES);
|
2015-04-26 16:33:14 +02:00
|
|
|
|
2015-11-05 19:52:30 +01:00
|
|
|
oldcxt = MemoryContextSwitchTo(cxt);
|
2015-05-24 03:35:49 +02:00
|
|
|
|
2015-11-05 19:52:30 +01:00
|
|
|
proc = (PLyProcedure *) palloc0(sizeof(PLyProcedure));
|
|
|
|
proc->mcxt = cxt;
|
2011-12-18 20:14:16 +01:00
|
|
|
|
|
|
|
PG_TRY();
|
|
|
|
{
|
2015-11-05 19:52:30 +01:00
|
|
|
Datum protrftypes_datum;
|
|
|
|
Datum prosrcdatum;
|
|
|
|
bool isnull;
|
|
|
|
char *procSource;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
proc->proname = pstrdup(NameStr(procStruct->proname));
|
Allow memory contexts to have both fixed and variable ident strings.
Originally, we treated memory context names as potentially variable in
all cases, and therefore always copied them into the context header.
Commit 9fa6f00b1 rethought this a little bit and invented a distinction
between fixed and variable names, skipping the copy step for the former.
But we can make things both simpler and more useful by instead allowing
there to be two parts to a context's identification, a fixed "name" and
an optional, variable "ident". The name supplied in the context create
call is now required to be a compile-time-constant string in all cases,
as it is never copied but just pointed to. The "ident" string, if
wanted, is supplied later. This is needed because typically we want
the ident to be stored inside the context so that it's cleaned up
automatically on context deletion; that means it has to be copied into
the context before we can set the pointer.
The cost of this approach is basically just an additional pointer field
in struct MemoryContextData, which isn't much overhead, and is bought
back entirely in the AllocSet case by not needing a headerSize field
anymore, since we no longer have to cope with variable header length.
In addition, we can simplify the internal interfaces for memory context
creation still further, saving a few cycles there. And it's no longer
true that a custom identifier disqualifies a context from participating
in aset.c's freelist scheme, so possibly there's some win on that end.
All the places that were using non-compile-time-constant context names
are adjusted to put the variable info into the "ident" instead. This
allows more effective identification of those contexts in many cases;
for example, subsidary contexts of relcache entries are now identified
by both type (e.g. "index info") and relname, where before you got only
one or the other. Contexts associated with PL function cache entries
are now identified more fully and uniformly, too.
I also arranged for plancache contexts to use the query source string
as their identifier. This is basically free for CachedPlanSources, as
they contained a copy of that string already. We pay an extra pstrdup
to do it for CachedPlans. That could perhaps be avoided, but it would
make things more fragile (since the CachedPlanSource is sometimes
destroyed first). I suspect future improvements in error reporting will
require CachedPlans to have a copy of that string anyway, so it's not
clear that it's worth moving mountains to avoid it now.
This also changes the APIs for context statistics routines so that the
context-specific routines no longer assume that output goes straight
to stderr, nor do they know all details of the output format. This
is useful immediately to reduce code duplication, and it also allows
for external code to do something with stats output that's different
from printing to stderr.
The reason for pushing this now rather than waiting for v12 is that
it rethinks some of the API changes made by commit 9fa6f00b1. Seems
better for extension authors to endure just one round of API changes
not two.
Discussion: https://postgr.es/m/CAB=Je-FdtmFZ9y9REHD7VsSrnCkiBhsA4mdsLKSPauwXtQBeNA@mail.gmail.com
2018-03-27 22:46:47 +02:00
|
|
|
MemoryContextSetIdentifier(cxt, proc->proname);
|
2015-11-05 19:52:30 +01:00
|
|
|
proc->pyname = pstrdup(procName);
|
|
|
|
proc->fn_xmin = HeapTupleHeaderGetRawXmin(procTup->t_data);
|
|
|
|
proc->fn_tid = procTup->t_self;
|
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 20:50:30 +02:00
|
|
|
proc->fn_readonly = (procStruct->provolatile != PROVOLATILE_VOLATILE);
|
|
|
|
proc->is_setof = procStruct->proretset;
|
2018-03-02 14:57:38 +01:00
|
|
|
proc->is_procedure = (procStruct->prokind == PROKIND_PROCEDURE);
|
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 20:50:30 +02:00
|
|
|
proc->src = NULL;
|
|
|
|
proc->argnames = NULL;
|
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 22:22:57 +01:00
|
|
|
proc->args = NULL;
|
2015-11-05 19:52:30 +01:00
|
|
|
proc->nargs = 0;
|
|
|
|
proc->langid = procStruct->prolang;
|
|
|
|
protrftypes_datum = SysCacheGetAttr(PROCOID, procTup,
|
|
|
|
Anum_pg_proc_protrftypes,
|
|
|
|
&isnull);
|
|
|
|
proc->trftypes = isnull ? NIL : oid_array_to_list(protrftypes_datum);
|
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 20:50:30 +02:00
|
|
|
proc->code = NULL;
|
|
|
|
proc->statics = NULL;
|
2015-11-05 19:52:30 +01:00
|
|
|
proc->globals = NULL;
|
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 20:50:30 +02:00
|
|
|
proc->calldepth = 0;
|
|
|
|
proc->argstack = NULL;
|
2015-11-05 19:52:30 +01:00
|
|
|
|
2011-12-18 20:14:16 +01:00
|
|
|
/*
|
|
|
|
* get information required for output conversion of the return value,
|
2018-03-05 17:51:15 +01:00
|
|
|
* but only if this isn't a trigger.
|
2011-12-18 20:14:16 +01:00
|
|
|
*/
|
2018-03-05 17:51:15 +01:00
|
|
|
if (!is_trigger)
|
2011-12-18 20:14:16 +01:00
|
|
|
{
|
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 22:22:57 +01:00
|
|
|
Oid rettype = procStruct->prorettype;
|
2011-12-18 20:14:16 +01:00
|
|
|
HeapTuple rvTypeTup;
|
|
|
|
Form_pg_type rvTypeStruct;
|
|
|
|
|
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 22:22:57 +01:00
|
|
|
rvTypeTup = SearchSysCache1(TYPEOID, ObjectIdGetDatum(rettype));
|
2011-12-18 20:14:16 +01:00
|
|
|
if (!HeapTupleIsValid(rvTypeTup))
|
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 22:22:57 +01:00
|
|
|
elog(ERROR, "cache lookup failed for type %u", rettype);
|
2011-12-18 20:14:16 +01:00
|
|
|
rvTypeStruct = (Form_pg_type) GETSTRUCT(rvTypeTup);
|
|
|
|
|
|
|
|
/* Disallow pseudotype result, except for void or record */
|
|
|
|
if (rvTypeStruct->typtype == TYPTYPE_PSEUDO)
|
|
|
|
{
|
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 22:22:57 +01:00
|
|
|
if (rettype == VOIDOID ||
|
|
|
|
rettype == RECORDOID)
|
|
|
|
/* okay */ ;
|
Don't use custom OID symbols in pg_type.dat, either.
On the same reasoning as in commit 36b931214, forbid using custom
oid_symbol macros in pg_type as well as pg_proc, so that we always
rely on the predictable macro names generated by genbki.pl.
We do continue to grant grandfather status to the names CASHOID and
LSNOID, although those are now considered deprecated aliases for the
preferred names MONEYOID and PG_LSNOID. This is because there's
likely to be client-side code using the old names, and this bout of
neatnik-ism doesn't quite seem worth breaking client code.
There might be a case for grandfathering EVTTRIGGEROID, too, since
externally-maintained PLs may reference that symbol. But renaming
such references to EVENT_TRIGGEROID doesn't seem like a particularly
heavy lift --- we make far more significant backend API changes in
every major release. For now I didn't add that, but we could
reconsider if there's pushback.
The other names changed here seem pretty unlikely to have any outside
uses. Again, we could add alias macros if there are complaints, but
for now I didn't.
As before, no need for a catversion bump.
John Naylor
Discussion: https://postgr.es/m/CAFBsxsHpCbjfoddNGpnnnY5pHwckWfiYkMYSF74PmP1su0+ZOw@mail.gmail.com
2020-10-29 18:33:38 +01:00
|
|
|
else if (rettype == TRIGGEROID || rettype == EVENT_TRIGGEROID)
|
2011-12-18 20:14:16 +01:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
errmsg("trigger functions can only be called as triggers")));
|
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 22:22:57 +01:00
|
|
|
else
|
2011-12-18 20:14:16 +01:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
errmsg("PL/Python functions cannot return type %s",
|
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 22:22:57 +01:00
|
|
|
format_type_be(rettype))));
|
2011-12-18 20:14:16 +01:00
|
|
|
}
|
|
|
|
|
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 22:22:57 +01:00
|
|
|
/* set up output function for procedure result */
|
|
|
|
PLy_output_setup_func(&proc->result, proc->mcxt,
|
|
|
|
rettype, -1, proc);
|
2011-12-18 20:14:16 +01:00
|
|
|
|
|
|
|
ReleaseSysCache(rvTypeTup);
|
|
|
|
}
|
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 22:22:57 +01:00
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* In a trigger function, we use proc->result and proc->result_in
|
|
|
|
* for converting tuples, but we don't yet have enough info to set
|
|
|
|
* them up. PLy_exec_trigger will deal with it.
|
|
|
|
*/
|
|
|
|
proc->result.typoid = InvalidOid;
|
|
|
|
proc->result_in.typoid = InvalidOid;
|
|
|
|
}
|
2011-12-18 20:14:16 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Now get information required for input conversion of the
|
|
|
|
* procedure's arguments. Note that we ignore output arguments here.
|
|
|
|
* If the function returns record, those I/O functions will be set up
|
|
|
|
* when the function is first called.
|
|
|
|
*/
|
|
|
|
if (procStruct->pronargs)
|
|
|
|
{
|
|
|
|
Oid *types;
|
|
|
|
char **names,
|
|
|
|
*modes;
|
2015-11-05 19:52:30 +01:00
|
|
|
int pos,
|
2011-12-18 20:14:16 +01:00
|
|
|
total;
|
|
|
|
|
|
|
|
/* extract argument type info from the pg_proc tuple */
|
|
|
|
total = get_func_arg_info(procTup, &types, &names, &modes);
|
|
|
|
|
|
|
|
/* count number of in+inout args into proc->nargs */
|
|
|
|
if (modes == NULL)
|
|
|
|
proc->nargs = total;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* proc->nargs was initialized to 0 above */
|
|
|
|
for (i = 0; i < total; i++)
|
|
|
|
{
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
if (modes[i] != PROARGMODE_OUT &&
|
2011-12-18 20:14:16 +01:00
|
|
|
modes[i] != PROARGMODE_TABLE)
|
|
|
|
(proc->nargs)++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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 22:22:57 +01:00
|
|
|
/* Allocate arrays for per-input-argument data */
|
2015-11-05 19:52:30 +01:00
|
|
|
proc->argnames = (char **) palloc0(sizeof(char *) * proc->nargs);
|
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 22:22:57 +01:00
|
|
|
proc->args = (PLyDatumToOb *) palloc0(sizeof(PLyDatumToOb) * proc->nargs);
|
|
|
|
|
2011-12-18 20:14:16 +01:00
|
|
|
for (i = pos = 0; i < total; i++)
|
|
|
|
{
|
|
|
|
HeapTuple argTypeTup;
|
|
|
|
Form_pg_type argTypeStruct;
|
|
|
|
|
|
|
|
if (modes &&
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
(modes[i] == PROARGMODE_OUT ||
|
2011-12-18 20:14:16 +01:00
|
|
|
modes[i] == PROARGMODE_TABLE))
|
|
|
|
continue; /* skip OUT arguments */
|
|
|
|
|
|
|
|
Assert(types[i] == procStruct->proargtypes.values[pos]);
|
|
|
|
|
|
|
|
argTypeTup = SearchSysCache1(TYPEOID,
|
|
|
|
ObjectIdGetDatum(types[i]));
|
|
|
|
if (!HeapTupleIsValid(argTypeTup))
|
|
|
|
elog(ERROR, "cache lookup failed for type %u", types[i]);
|
|
|
|
argTypeStruct = (Form_pg_type) GETSTRUCT(argTypeTup);
|
|
|
|
|
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 22:22:57 +01:00
|
|
|
/* disallow pseudotype arguments */
|
|
|
|
if (argTypeStruct->typtype == TYPTYPE_PSEUDO)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
errmsg("PL/Python functions cannot accept type %s",
|
|
|
|
format_type_be(types[i]))));
|
|
|
|
|
|
|
|
/* set up I/O function info */
|
|
|
|
PLy_input_setup_func(&proc->args[pos], proc->mcxt,
|
|
|
|
types[i], -1, /* typmod not known */
|
|
|
|
proc);
|
2011-12-18 20:14:16 +01:00
|
|
|
|
|
|
|
/* get argument name */
|
2015-11-05 19:52:30 +01:00
|
|
|
proc->argnames[pos] = names ? pstrdup(names[i]) : NULL;
|
2011-12-18 20:14:16 +01:00
|
|
|
|
|
|
|
ReleaseSysCache(argTypeTup);
|
|
|
|
|
|
|
|
pos++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* get the text of the function.
|
|
|
|
*/
|
2023-03-25 22:49:33 +01:00
|
|
|
prosrcdatum = SysCacheGetAttrNotNull(PROCOID, procTup,
|
|
|
|
Anum_pg_proc_prosrc);
|
2011-12-18 20:14:16 +01:00
|
|
|
procSource = TextDatumGetCString(prosrcdatum);
|
|
|
|
|
|
|
|
PLy_procedure_compile(proc, procSource);
|
|
|
|
|
|
|
|
pfree(procSource);
|
|
|
|
}
|
|
|
|
PG_CATCH();
|
|
|
|
{
|
2015-11-05 19:52:30 +01:00
|
|
|
MemoryContextSwitchTo(oldcxt);
|
2011-12-18 20:14:16 +01:00
|
|
|
PLy_procedure_delete(proc);
|
|
|
|
PG_RE_THROW();
|
|
|
|
}
|
|
|
|
PG_END_TRY();
|
|
|
|
|
2015-11-05 19:52:30 +01:00
|
|
|
MemoryContextSwitchTo(oldcxt);
|
2011-12-18 20:14:16 +01:00
|
|
|
return proc;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Insert the procedure into the Python interpreter
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
PLy_procedure_compile(PLyProcedure *proc, const char *src)
|
|
|
|
{
|
|
|
|
PyObject *crv = NULL;
|
|
|
|
char *msrc;
|
|
|
|
|
|
|
|
proc->globals = PyDict_Copy(PLy_interp_globals);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* SD is private preserved data between calls. GD is global data shared by
|
|
|
|
* all functions
|
|
|
|
*/
|
|
|
|
proc->statics = PyDict_New();
|
2017-10-31 15:49:36 +01:00
|
|
|
if (!proc->statics)
|
|
|
|
PLy_elog(ERROR, NULL);
|
2011-12-18 20:14:16 +01:00
|
|
|
PyDict_SetItemString(proc->globals, "SD", proc->statics);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* insert the function code into the interpreter
|
|
|
|
*/
|
|
|
|
msrc = PLy_procedure_munge_source(proc->pyname, src);
|
|
|
|
/* Save the mangled source for later inclusion in tracebacks */
|
2015-11-05 19:52:30 +01:00
|
|
|
proc->src = MemoryContextStrdup(proc->mcxt, msrc);
|
2011-12-18 20:14:16 +01:00
|
|
|
crv = PyRun_String(msrc, Py_file_input, proc->globals, NULL);
|
|
|
|
pfree(msrc);
|
|
|
|
|
|
|
|
if (crv != NULL)
|
|
|
|
{
|
|
|
|
int clen;
|
|
|
|
char call[NAMEDATALEN + 256];
|
|
|
|
|
|
|
|
Py_DECREF(crv);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* compile a call to the function
|
|
|
|
*/
|
|
|
|
clen = snprintf(call, sizeof(call), "%s()", proc->pyname);
|
|
|
|
if (clen < 0 || clen >= sizeof(call))
|
|
|
|
elog(ERROR, "string would overflow buffer");
|
|
|
|
proc->code = Py_CompileString(call, "<string>", Py_eval_input);
|
|
|
|
if (proc->code != NULL)
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (proc->proname)
|
|
|
|
PLy_elog(ERROR, "could not compile PL/Python function \"%s\"",
|
|
|
|
proc->proname);
|
|
|
|
else
|
|
|
|
PLy_elog(ERROR, "could not compile anonymous PL/Python code block");
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
PLy_procedure_delete(PLyProcedure *proc)
|
|
|
|
{
|
|
|
|
Py_XDECREF(proc->code);
|
|
|
|
Py_XDECREF(proc->statics);
|
|
|
|
Py_XDECREF(proc->globals);
|
2015-11-05 19:52:30 +01:00
|
|
|
MemoryContextDelete(proc->mcxt);
|
2011-12-18 20:14:16 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Decide whether a cached PLyProcedure struct is still valid
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
PLy_procedure_valid(PLyProcedure *proc, HeapTuple procTup)
|
|
|
|
{
|
2015-11-05 19:52:30 +01:00
|
|
|
if (proc == NULL)
|
|
|
|
return false;
|
2011-12-18 20:14:16 +01:00
|
|
|
|
|
|
|
/* If the pg_proc tuple has changed, it's not valid */
|
2013-12-22 21:49:09 +01:00
|
|
|
if (!(proc->fn_xmin == HeapTupleHeaderGetRawXmin(procTup->t_data) &&
|
2011-12-18 20:14:16 +01:00
|
|
|
ItemPointerEquals(&proc->fn_tid, &procTup->t_self)))
|
|
|
|
return false;
|
|
|
|
|
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 22:22:57 +01:00
|
|
|
return true;
|
2011-12-18 20:14:16 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static char *
|
|
|
|
PLy_procedure_munge_source(const char *name, const char *src)
|
|
|
|
{
|
|
|
|
char *mrc,
|
|
|
|
*mp;
|
|
|
|
const char *sp;
|
2013-07-02 16:23:42 +02:00
|
|
|
size_t mlen;
|
|
|
|
int plen;
|
2011-12-18 20:14:16 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* room for function source and the def statement
|
|
|
|
*/
|
|
|
|
mlen = (strlen(src) * 2) + strlen(name) + 16;
|
|
|
|
|
|
|
|
mrc = palloc(mlen);
|
|
|
|
plen = snprintf(mrc, mlen, "def %s():\n\t", name);
|
|
|
|
Assert(plen >= 0 && plen < mlen);
|
|
|
|
|
|
|
|
sp = src;
|
|
|
|
mp = mrc + plen;
|
|
|
|
|
|
|
|
while (*sp != '\0')
|
|
|
|
{
|
|
|
|
if (*sp == '\r' && *(sp + 1) == '\n')
|
|
|
|
sp++;
|
|
|
|
|
|
|
|
if (*sp == '\n' || *sp == '\r')
|
|
|
|
{
|
|
|
|
*mp++ = '\n';
|
|
|
|
*mp++ = '\t';
|
|
|
|
sp++;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
*mp++ = *sp++;
|
|
|
|
}
|
|
|
|
*mp++ = '\n';
|
|
|
|
*mp++ = '\n';
|
|
|
|
*mp = '\0';
|
|
|
|
|
|
|
|
if (mp > (mrc + mlen))
|
2019-08-05 05:14:58 +02:00
|
|
|
elog(FATAL, "buffer overrun in PLy_procedure_munge_source");
|
2011-12-18 20:14:16 +01:00
|
|
|
|
|
|
|
return mrc;
|
|
|
|
}
|