1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-08 11:42:09 +03:00

Arrange for function default arguments to be processed properly in expressions

that are set up for execution with ExecPrepareExpr rather than going through
the full planner process.  By introducing an explicit notion of "expression
planning", this patch also lays a bit of groundwork for maybe someday
allowing sub-selects in standalone expressions.
This commit is contained in:
Tom Lane
2009-01-09 15:46:11 +00:00
parent d3706cb6d2
commit d04db37072
7 changed files with 73 additions and 21 deletions

View File

@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.250 2009/01/01 17:23:44 momjian Exp $
* $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.251 2009/01/09 15:46:10 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -2576,3 +2576,39 @@ get_column_info_for_window(PlannerInfo *root, WindowClause *wc, List *tlist,
elog(ERROR, "failed to deconstruct sort operators into partitioning/ordering operators");
}
}
/*
* expression_planner
* Perform planner's transformations on a standalone expression.
*
* Various utility commands need to evaluate expressions that are not part
* of a plannable query. They can do so using the executor's regular
* expression-execution machinery, but first the expression has to be fed
* through here to transform it from parser output to something executable.
*
* Currently, we disallow sublinks in standalone expressions, so there's no
* real "planning" involved here. (That might not always be true though.)
* What we must do is run eval_const_expressions to ensure that any function
* default arguments get inserted. The fact that constant subexpressions
* get simplified is a side-effect that is useful when the expression will
* get evaluated more than once. Also, we must fix operator function IDs.
*
* Note: this must not make any damaging changes to the passed-in expression
* tree. (It would actually be okay to apply fix_opfuncids to it, but since
* we first do an expression_tree_mutator-based walk, what is returned will
* be a new node tree.)
*/
Expr *
expression_planner(Expr *expr)
{
Node *result;
/* Insert default arguments and simplify constant subexprs */
result = eval_const_expressions(NULL, (Node *) expr);
/* Fill in opfuncid values if missing */
fix_opfuncids(result);
return (Expr *) result;
}