1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-07 00:36:50 +03:00

Rethink the "read/write parameter" mechanism in pl/pgsql.

Performance issues with the preceding patch to re-implement array
element assignment within pl/pgsql led me to realize that the read/write
parameter mechanism is misdesigned.  Instead of requiring the assignment
source expression to be such that *all* its references to the target
variable could be passed as R/W, we really want to identify *one*
reference to the target variable to be passed as R/W, allowing any other
ones to be passed read/only as they would be by default.  As long as the
R/W reference is a direct argument to the top-level (hence last to be
executed) function in the expression, there is no harm in R/O references
being passed to other lower parts of the expression.  Nor is there any
use-case for more than one argument of the top-level function being R/W.

Hence, rewrite that logic to identify one single Param that references
the target variable, and make only that Param pass a read/write
reference, not any other Params referencing the target variable.

Discussion: https://postgr.es/m/4165684.1607707277@sss.pgh.pa.us
This commit is contained in:
Tom Lane
2021-01-04 12:39:27 -05:00
parent 1788828d33
commit 1c1cbe279b
4 changed files with 107 additions and 97 deletions

View File

@ -2582,8 +2582,11 @@ array_set_element_expanded(Datum arraydatum,
/*
* Copy new element into array's context, if needed (we assume it's
* already detoasted, so no junk should be created). If we fail further
* down, this memory is leaked, but that's reasonably harmless.
* already detoasted, so no junk should be created). Doing this before
* we've made any significant changes ensures that our behavior is sane
* even when the source is a reference to some element of this same array.
* If we fail further down, this memory is leaked, but that's reasonably
* harmless.
*/
if (!eah->typbyval && !isNull)
{