gitlab-pg_query 1.3.1 → 2.0.4

data/ext/pg_query/src_backend_utils_fmgr_fmgr.c

@@ -0,0 +1,570 @@
+/*--------------------------------------------------------------------
+ * Symbols referenced in this file:
+ * - FunctionCall5Coll
+ *--------------------------------------------------------------------
+ */
+
+/*-------------------------------------------------------------------------
+ *
+ * fmgr.c
+ *	  The Postgres function manager.
+ *
+ * Portions Copyright (c) 1996-2020, PostgreSQL Global Development Group
+ * Portions Copyright (c) 1994, Regents of the University of California
+ *
+ *
+ * IDENTIFICATION
+ *	  src/backend/utils/fmgr/fmgr.c
+ *
+ *-------------------------------------------------------------------------
+ */
+
+#include "postgres.h"
+
+#include "access/detoast.h"
+#include "catalog/pg_language.h"
+#include "catalog/pg_proc.h"
+#include "catalog/pg_type.h"
+#include "executor/functions.h"
+#include "lib/stringinfo.h"
+#include "miscadmin.h"
+#include "nodes/makefuncs.h"
+#include "nodes/nodeFuncs.h"
+#include "pgstat.h"
+#include "utils/acl.h"
+#include "utils/builtins.h"
+#include "utils/fmgrtab.h"
+#include "utils/guc.h"
+#include "utils/lsyscache.h"
+#include "utils/syscache.h"
+
+/*
+ * Hooks for function calls
+ */
+PGDLLIMPORT
+
+PGDLLIMPORT
+
+
+/*
+ * Hashtable for fast lookup of external C functions
+ */
+typedef struct
+{
+	/* fn_oid is the hash key and so must be first! */
+	Oid			fn_oid;			/* OID of an external C function */
+	TransactionId fn_xmin;		/* for checking up-to-dateness */
+	ItemPointerData fn_tid;
+	PGFunction	user_fn;		/* the function's address */
+	const Pg_finfo_record *inforec; /* address of its info record */
+} CFuncHashTabEntry;
+
+
+
+
+static void fmgr_info_cxt_security(Oid functionId, FmgrInfo *finfo, MemoryContext mcxt,
+								   bool ignore_security);
+static void fmgr_info_C_lang(Oid functionId, FmgrInfo *finfo, HeapTuple procedureTuple);
+static void fmgr_info_other_lang(Oid functionId, FmgrInfo *finfo, HeapTuple procedureTuple);
+static CFuncHashTabEntry *lookup_C_func(HeapTuple procedureTuple);
+static void record_C_func(HeapTuple procedureTuple,
+						  PGFunction user_fn, const Pg_finfo_record *inforec);
+
+/* extern so it's callable via JIT */
+extern Datum fmgr_security_definer(PG_FUNCTION_ARGS);
+
+
+/*
+ * Lookup routines for builtin-function table.  We can search by either Oid
+ * or name, but search by Oid is much faster.
+ */
+
+
+
+/*
+ * Lookup a builtin by name.  Note there can be more than one entry in
+ * the array with the same name, but they should all point to the same
+ * routine.
+ */
+
+
+/*
+ * This routine fills a FmgrInfo struct, given the OID
+ * of the function to be called.
+ *
+ * The caller's CurrentMemoryContext is used as the fn_mcxt of the info
+ * struct; this means that any subsidiary data attached to the info struct
+ * (either by fmgr_info itself, or later on by a function call handler)
+ * will be allocated in that context.  The caller must ensure that this
+ * context is at least as long-lived as the info struct itself.  This is
+ * not a problem in typical cases where the info struct is on the stack or
+ * in freshly-palloc'd space.  However, if one intends to store an info
+ * struct in a long-lived table, it's better to use fmgr_info_cxt.
+ */
+
+
+/*
+ * Fill a FmgrInfo struct, specifying a memory context in which its
+ * subsidiary data should go.
+ */
+
+
+/*
+ * This one does the actual work.  ignore_security is ordinarily false
+ * but is set to true when we need to avoid recursion.
+ */
+
+
+/*
+ * Return module and C function name providing implementation of functionId.
+ *
+ * If *mod == NULL and *fn == NULL, no C symbol is known to implement
+ * function.
+ *
+ * If *mod == NULL and *fn != NULL, the function is implemented by a symbol in
+ * the main binary.
+ *
+ * If *mod != NULL and *fn !=NULL the function is implemented in an extension
+ * shared object.
+ *
+ * The returned module and function names are pstrdup'ed into the current
+ * memory context.
+ */
+
+
+
+/*
+ * Special fmgr_info processing for C-language functions.  Note that
+ * finfo->fn_oid is not valid yet.
+ */
+
+
+/*
+ * Special fmgr_info processing for other-language functions.  Note
+ * that finfo->fn_oid is not valid yet.
+ */
+
+
+/*
+ * Fetch and validate the information record for the given external function.
+ * The function is specified by a handle for the containing library
+ * (obtained from load_external_function) as well as the function name.
+ *
+ * If no info function exists for the given name an error is raised.
+ *
+ * This function is broken out of fmgr_info_C_lang so that fmgr_c_validator
+ * can validate the information record for a function not yet entered into
+ * pg_proc.
+ */
+
+
+
+/*-------------------------------------------------------------------------
+ *		Routines for caching lookup information for external C functions.
+ *
+ * The routines in dfmgr.c are relatively slow, so we try to avoid running
+ * them more than once per external function per session.  We use a hash table
+ * with the function OID as the lookup key.
+ *-------------------------------------------------------------------------
+ */
+
+/*
+ * lookup_C_func: try to find a C function in the hash table
+ *
+ * If an entry exists and is up to date, return it; else return NULL
+ */
+
+
+/*
+ * record_C_func: enter (or update) info about a C function in the hash table
+ */
+
+
+/*
+ * clear_external_function_hash: remove entries for a library being closed
+ *
+ * Presently we just zap the entire hash table, but later it might be worth
+ * the effort to remove only the entries associated with the given handle.
+ */
+
+
+
+/*
+ * Copy an FmgrInfo struct
+ *
+ * This is inherently somewhat bogus since we can't reliably duplicate
+ * language-dependent subsidiary info.  We cheat by zeroing fn_extra,
+ * instead, meaning that subsidiary info will have to be recomputed.
+ */
+
+
+
+/*
+ * Specialized lookup routine for fmgr_internal_validator: given the alleged
+ * name of an internal function, return the OID of the function.
+ * If the name is not recognized, return InvalidOid.
+ */
+
+
+
+/*
+ * Support for security-definer and proconfig-using functions.  We support
+ * both of these features using the same call handler, because they are
+ * often used together and it would be inefficient (as well as notationally
+ * messy) to have two levels of call handler involved.
+ */
+struct fmgr_security_definer_cache
+{
+	FmgrInfo	flinfo;			/* lookup info for target function */
+	Oid			userid;			/* userid to set, or InvalidOid */
+	ArrayType  *proconfig;		/* GUC values to set, or NULL */
+	Datum		arg;			/* passthrough argument for plugin modules */
+};
+
+/*
+ * Function handler for security-definer/proconfig/plugin-hooked functions.
+ * We extract the OID of the actual function and do a fmgr lookup again.
+ * Then we fetch the pg_proc row and copy the owner ID and proconfig fields.
+ * (All this info is cached for the duration of the current query.)
+ * To execute a call, we temporarily replace the flinfo with the cached
+ * and looked-up one, while keeping the outer fcinfo (which contains all
+ * the actual arguments, etc.) intact.  This is not re-entrant, but then
+ * the fcinfo itself can't be used reentrantly anyway.
+ */
+
+
+
+/*-------------------------------------------------------------------------
+ *		Support routines for callers of fmgr-compatible functions
+ *-------------------------------------------------------------------------
+ */
+
+/*
+ * These are for invocation of a specifically named function with a
+ * directly-computed parameter list.  Note that neither arguments nor result
+ * are allowed to be NULL.  Also, the function cannot be one that needs to
+ * look at FmgrInfo, since there won't be any.
+ */
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+/*
+ * These functions work like the DirectFunctionCall functions except that
+ * they use the flinfo parameter to initialise the fcinfo for the call.
+ * It's recommended that the callee only use the fn_extra and fn_mcxt
+ * fields, as other fields will typically describe the calling function
+ * not the callee.  Conversely, the calling function should not have
+ * used fn_extra, unless its use is known to be compatible with the callee's.
+ */
+
+
+
+
+
+/*
+ * These are for invocation of a previously-looked-up function with a
+ * directly-computed parameter list.  Note that neither arguments nor result
+ * are allowed to be NULL.
+ */
+
+
+
+
+
+
+
+
+
+
+Datum
+FunctionCall5Coll(FmgrInfo *flinfo, Oid collation, Datum arg1, Datum arg2,
+				  Datum arg3, Datum arg4, Datum arg5)
+{
+	LOCAL_FCINFO(fcinfo, 5);
+	Datum		result;
+
+	InitFunctionCallInfoData(*fcinfo, flinfo, 5, collation, NULL, NULL);
+
+	fcinfo->args[0].value = arg1;
+	fcinfo->args[0].isnull = false;
+	fcinfo->args[1].value = arg2;
+	fcinfo->args[1].isnull = false;
+	fcinfo->args[2].value = arg3;
+	fcinfo->args[2].isnull = false;
+	fcinfo->args[3].value = arg4;
+	fcinfo->args[3].isnull = false;
+	fcinfo->args[4].value = arg5;
+	fcinfo->args[4].isnull = false;
+
+	result = FunctionCallInvoke(fcinfo);
+
+	/* Check for null result, since caller is clearly not expecting one */
+	if (fcinfo->isnull)
+		elog(ERROR, "function %u returned NULL", flinfo->fn_oid);
+
+	return result;
+}
+
+
+
+
+
+
+
+
+
+
+/*
+ * These are for invocation of a function identified by OID with a
+ * directly-computed parameter list.  Note that neither arguments nor result
+ * are allowed to be NULL.  These are essentially fmgr_info() followed
+ * by FunctionCallN().  If the same function is to be invoked repeatedly,
+ * do the fmgr_info() once and then use FunctionCallN().
+ */
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+/*
+ * Special cases for convenient invocation of datatype I/O functions.
+ */
+
+/*
+ * Call a previously-looked-up datatype input function.
+ *
+ * "str" may be NULL to indicate we are reading a NULL.  In this case
+ * the caller should assume the result is NULL, but we'll call the input
+ * function anyway if it's not strict.  So this is almost but not quite
+ * the same as FunctionCall3.
+ */
+
+
+/*
+ * Call a previously-looked-up datatype output function.
+ *
+ * Do not call this on NULL datums.
+ *
+ * This is currently little more than window dressing for FunctionCall1.
+ */
+
+
+/*
+ * Call a previously-looked-up datatype binary-input function.
+ *
+ * "buf" may be NULL to indicate we are reading a NULL.  In this case
+ * the caller should assume the result is NULL, but we'll call the receive
+ * function anyway if it's not strict.  So this is almost but not quite
+ * the same as FunctionCall3.
+ */
+
+
+/*
+ * Call a previously-looked-up datatype binary-output function.
+ *
+ * Do not call this on NULL datums.
+ *
+ * This is little more than window dressing for FunctionCall1, but it does
+ * guarantee a non-toasted result, which strictly speaking the underlying
+ * function doesn't.
+ */
+
+
+/*
+ * As above, for I/O functions identified by OID.  These are only to be used
+ * in seldom-executed code paths.  They are not only slow but leak memory.
+ */
+
+
+
+
+
+
+
+
+
+/*-------------------------------------------------------------------------
+ *		Support routines for standard maybe-pass-by-reference datatypes
+ *
+ * int8 and float8 can be passed by value if Datum is wide enough.
+ * (For backwards-compatibility reasons, we allow pass-by-ref to be chosen
+ * at compile time even if pass-by-val is possible.)
+ *
+ * Note: there is only one switch controlling the pass-by-value option for
+ * both int8 and float8; this is to avoid making things unduly complicated
+ * for the timestamp types, which might have either representation.
+ *-------------------------------------------------------------------------
+ */
+
+#ifndef USE_FLOAT8_BYVAL		/* controls int8 too */
+
+Datum
+Int64GetDatum(int64 X)
+{
+	int64	   *retval = (int64 *) palloc(sizeof(int64));
+
+	*retval = X;
+	return PointerGetDatum(retval);
+}
+
+Datum
+Float8GetDatum(float8 X)
+{
+	float8	   *retval = (float8 *) palloc(sizeof(float8));
+
+	*retval = X;
+	return PointerGetDatum(retval);
+}
+#endif							/* USE_FLOAT8_BYVAL */
+
+
+/*-------------------------------------------------------------------------
+ *		Support routines for toastable datatypes
+ *-------------------------------------------------------------------------
+ */
+
+
+
+
+
+
+
+
+
+/*-------------------------------------------------------------------------
+ *		Support routines for extracting info from fn_expr parse tree
+ *
+ * These are needed by polymorphic functions, which accept multiple possible
+ * input types and need help from the parser to know what they've got.
+ * Also, some functions might be interested in whether a parameter is constant.
+ * Functions taking VARIADIC ANY also need to know about the VARIADIC keyword.
+ *-------------------------------------------------------------------------
+ */
+
+/*
+ * Get the actual type OID of the function return type
+ *
+ * Returns InvalidOid if information is not available
+ */
+
+
+/*
+ * Get the actual type OID of a specific function argument (counting from 0)
+ *
+ * Returns InvalidOid if information is not available
+ */
+
+
+/*
+ * Get the actual type OID of a specific function argument (counting from 0),
+ * but working from the calling expression tree instead of FmgrInfo
+ *
+ * Returns InvalidOid if information is not available
+ */
+
+
+/*
+ * Find out whether a specific function argument is constant for the
+ * duration of a query
+ *
+ * Returns false if information is not available
+ */
+
+
+/*
+ * Find out whether a specific function argument is constant for the
+ * duration of a query, but working from the calling expression tree
+ *
+ * Returns false if information is not available
+ */
+
+
+/*
+ * Get the VARIADIC flag from the function invocation
+ *
+ * Returns false (the default assumption) if information is not available
+ *
+ * Note this is generally only of interest to VARIADIC ANY functions
+ */
+
+
+/*
+ * Set options to FmgrInfo of opclass support function.
+ *
+ * Opclass support functions are called outside of expressions.  Thanks to that
+ * we can use fn_expr to store opclass options as bytea constant.
+ */
+
+
+/*
+ * Check if options are defined for opclass support function.
+ */
+
+
+/*
+ * Get options for opclass support function.
+ */
+
+
+/*-------------------------------------------------------------------------
+ *		Support routines for procedural language implementations
+ *-------------------------------------------------------------------------
+ */
+
+/*
+ * Verify that a validator is actually associated with the language of a
+ * particular function and that the user has access to both the language and
+ * the function.  All validators should call this before doing anything
+ * substantial.  Doing so ensures a user cannot achieve anything with explicit
+ * calls to validators that he could not achieve with CREATE FUNCTION or by
+ * simply calling an existing function.
+ *
+ * When this function returns false, callers should skip all validation work
+ * and call PG_RETURN_VOID().  This never happens at present; it is reserved
+ * for future expansion.
+ *
+ * In particular, checking that the validator corresponds to the function's
+ * language allows untrusted language validators to assume they process only
+ * superuser-chosen source code.  (Untrusted language call handlers, by
+ * definition, do assume that.)  A user lacking the USAGE language privilege
+ * would be unable to reach the validator through CREATE FUNCTION, so we check
+ * that to block explicit calls as well.  Checking the EXECUTE privilege on
+ * the function is often superfluous, because most users can clone the
+ * function to get an executable copy.  It is meaningful against users with no
+ * database TEMP right and no permanent schema CREATE right, thereby unable to
+ * create any function.  Also, if the function tracks persistent state by
+ * function OID or name, validating the original function might permit more
+ * mischief than creating and validating a clone thereof.
+ */
+