mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Improve comments for execExpr.c's handling of FieldStore subexpressions.

Browse Source 
Given this code's general eagerness to use subexpressions' output variables
as temporary workspace, it's not exactly clear that it is safe for
FieldStore to tell a newval subexpression that it can write into the same
variable that is being supplied as a potential input.  Document the chain
of assumptions needed for that to be safe.
This commit is contained in:
Tom Lane 2017-07-15 16:57:43 -04:00
parent e9b64824a0
commit de2af6e001
1 changed files with 12 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
src/backend/executor/execExpr.c
View File

@ -1116,6 +1116,18 @@ ExecInitExprRec(Expr *node, PlanState *parent, ExprState *state,
* field assignment can't be within a CASE either. (So * field assignment can't be within a CASE either. (So
* saving and restoring innermost_caseval is just * saving and restoring innermost_caseval is just
* paranoia, but let's do it anyway.) * paranoia, but let's do it anyway.)
*
* Another non-obvious point is that it's safe to use the
* field's values[]/nulls[] entries as both the caseval
* source and the result address for this subexpression.
* That's okay only because (1) both FieldStore and
* ArrayRef evaluate their arg or refexpr inputs first,
* and (2) any such CaseTestExpr is directly the arg or
* refexpr input. So any read of the caseval will occur
* before there's a chance to overwrite it. Also, if
* multiple entries in the newvals/fieldnums lists target
* the same field, they'll effectively be applied
* left-to-right which is what we want.
*/ */
save_innermost_caseval = state->innermost_caseval; save_innermost_caseval = state->innermost_caseval;
save_innermost_casenull = state->innermost_casenull; save_innermost_casenull = state->innermost_casenull;