|
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
|
|
|
|
* functions.h
|
|
|
|
|
* Declarations for execution of SQL-language functions.
|
|
|
|
|
*
|
|
|
|
|
*
|
|
|
|
|
* Portions Copyright (c) 1996-2024, PostgreSQL Global Development Group
|
|
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
|
*
|
|
|
|
|
* src/include/executor/functions.h
|
|
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
|
#ifndef FUNCTIONS_H
|
|
|
|
|
#define FUNCTIONS_H
|
|
|
|
|
|
|
|
|
|
#include "nodes/execnodes.h"
|
|
|
|
|
#include "tcop/dest.h"
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Data structure needed by the parser callback hooks to resolve parameter
|
|
|
|
|
* references during parsing of a SQL function's body. This is separate from
|
|
|
|
|
* SQLFunctionCache since we sometimes do parsing separately from execution.
|
|
|
|
|
*/
|
|
|
|
|
typedef struct SQLFunctionParseInfo
|
|
|
|
|
{
|
|
|
|
|
char *fname; /* function's name */
|
|
|
|
|
int nargs; /* number of input arguments */
|
|
|
|
|
Oid *argtypes; /* resolved types of input arguments */
|
|
|
|
|
char **argnames; /* names of input arguments; NULL if none */
|
|
|
|
|
/* Note that argnames[i] can be NULL, if some args are unnamed */
|
|
|
|
|
Oid collation; /* function's input collation, if known */
|
|
|
|
|
} SQLFunctionParseInfo;
|
|
|
|
|
|
|
|
|
|
typedef SQLFunctionParseInfo *SQLFunctionParseInfoPtr;
|
|
|
|
|
|
|
|
|
|
extern Datum fmgr_sql(PG_FUNCTION_ARGS);
|
|
|
|
|
|
|
|
|
|
extern SQLFunctionParseInfoPtr prepare_sql_fn_parse_info(HeapTuple procedureTuple,
|
|
|
|
|
Node *call_expr,
|
|
|
|
|
Oid inputCollation);
|
|
|
|
|
|
|
|
|
|
extern void sql_fn_parser_setup(struct ParseState *pstate,
|
|
|
|
|
SQLFunctionParseInfoPtr pinfo);
|
|
|
|
|
|
Fix list-munging bug that broke SQL function result coercions.
Since commit 913bbd88d, check_sql_fn_retval() can either insert type
coercion steps in-line in the Query that produces the SQL function's
results, or generate a new top-level Query to perform the coercions,
if modifying the Query's output in-place wouldn't be safe. However,
it appears that the latter case has never actually worked, because
the code tried to inject the new Query back into the query list it was
passed ... which is not the list that will be used for later processing
when we execute the SQL function "normally" (without inlining it).
So we ended up with no coercion happening at run-time, leading to
wrong results or crashes depending on the datatypes involved.
While the regression tests look like they cover this area well enough,
through a huge bit of bad luck all the test cases that exercise the
separate-Query path were checking either inline-able cases (which
accidentally didn't have the bug) or cases that are no-ops at runtime
(e.g., varchar to text), so that the failure to perform the coercion
wasn't obvious. The fact that the cases that don't work weren't
allowed at all before v13 probably contributed to not noticing the
problem sooner, too.
To fix, get rid of the separate "flat" list of Query nodes and instead
pass the real two-level list that is going to be used later. I chose
to make the same change in check_sql_fn_statements(), although that has
no actual bug, just so that we don't need that data structure at all.
This is an API change, as evidenced by the adjustments needed to
callers outside functions.c. That's a bit scary to be doing in a
released branch, but so far as I can tell from a quick search,
there are no outside callers of these functions (and they are
sufficiently specific to our semantics for SQL-language functions that
it's not apparent why any extension would need to call them). In any
case, v13 already changed the API of check_sql_fn_retval() compared to
prior branches.
Per report from pinker. Back-patch to v13 where this code came in.
Discussion: https://postgr.es/m/1603050466566-0.post@n3.nabble.com
5 years ago
|
|
|
extern void check_sql_fn_statements(List *queryTreeLists);
|
|
|
|
|
|
Fix list-munging bug that broke SQL function result coercions.
Since commit 913bbd88d, check_sql_fn_retval() can either insert type
coercion steps in-line in the Query that produces the SQL function's
results, or generate a new top-level Query to perform the coercions,
if modifying the Query's output in-place wouldn't be safe. However,
it appears that the latter case has never actually worked, because
the code tried to inject the new Query back into the query list it was
passed ... which is not the list that will be used for later processing
when we execute the SQL function "normally" (without inlining it).
So we ended up with no coercion happening at run-time, leading to
wrong results or crashes depending on the datatypes involved.
While the regression tests look like they cover this area well enough,
through a huge bit of bad luck all the test cases that exercise the
separate-Query path were checking either inline-able cases (which
accidentally didn't have the bug) or cases that are no-ops at runtime
(e.g., varchar to text), so that the failure to perform the coercion
wasn't obvious. The fact that the cases that don't work weren't
allowed at all before v13 probably contributed to not noticing the
problem sooner, too.
To fix, get rid of the separate "flat" list of Query nodes and instead
pass the real two-level list that is going to be used later. I chose
to make the same change in check_sql_fn_statements(), although that has
no actual bug, just so that we don't need that data structure at all.
This is an API change, as evidenced by the adjustments needed to
callers outside functions.c. That's a bit scary to be doing in a
released branch, but so far as I can tell from a quick search,
there are no outside callers of these functions (and they are
sufficiently specific to our semantics for SQL-language functions that
it's not apparent why any extension would need to call them). In any
case, v13 already changed the API of check_sql_fn_retval() compared to
prior branches.
Per report from pinker. Back-patch to v13 where this code came in.
Discussion: https://postgr.es/m/1603050466566-0.post@n3.nabble.com
5 years ago
|
|
|
extern bool check_sql_fn_retval(List *queryTreeLists,
|
|
|
|
|
Oid rettype, TupleDesc rettupdesc,
|
|
|
|
|
char prokind,
|
|
|
|
|
bool insertDroppedCols,
|
|
|
|
|
List **resultTargetList);
|
|
|
|
|
|
|
|
|
|
extern DestReceiver *CreateSQLFunctionDestReceiver(void);
|
|
|
|
|
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
9 years ago
|
|
|
#endif /* FUNCTIONS_H */
|
