Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 534d0ea

Browse files
committed
Generalize plpgsql's heuristic for importing expanded objects.
If a R/W expanded-object pointer is passed as a function parameter, take ownership of the object, regardless of its type. Previously this happened only for expanded arrays, but that was a result of sloppy thinking. (If the plpgsql function did not end by returning the object, the result would be to leak the object until the surrounding memory context is cleaned up. That's not awful, since non-expanded values have always been managed that way, but we can do better.) Per discussion with Michel Pelletier. There's a lot more to do here to make plpgsql work efficiently with expanded objects that aren't arrays, but this is an easy first step. Discussion: https://postgr.es/m/CACxu=vJaKFNsYxooSnW1wEgsAO5u_v1XYBacfVJ14wgJV_PYeg@mail.gmail.com
1 parent 67bab53 commit 534d0ea

File tree

1 file changed

+11
-10
lines changed

1 file changed

+11
-10
lines changed

src/pl/plpgsql/src/pl_exec.c

Lines changed: 11 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -532,21 +532,22 @@ plpgsql_exec_function(PLpgSQL_function *func, FunctionCallInfo fcinfo,
532532
false);
533533

534534
/*
535-
* Force any array-valued parameter to be stored in
535+
* If it's a varlena type, check to see if we received a
536+
* R/W expanded-object pointer. If so, we can commandeer
537+
* the object rather than having to copy it. If passed a
538+
* R/O expanded pointer, just keep it as the value of the
539+
* variable for the moment. (We can change it to R/W if
540+
* the variable gets modified, but that may very well
541+
* never happen.)
542+
*
543+
* Also, force any flat array value to be stored in
536544
* expanded form in our local variable, in hopes of
537545
* improving efficiency of uses of the variable. (This is
538546
* a hack, really: why only arrays? Need more thought
539547
* about which cases are likely to win. See also
540548
* typisarray-specific heuristic in exec_assign_value.)
541-
*
542-
* Special cases: If passed a R/W expanded pointer, assume
543-
* we can commandeer the object rather than having to copy
544-
* it. If passed a R/O expanded pointer, just keep it as
545-
* the value of the variable for the moment. (We'll force
546-
* it to R/W if the variable gets modified, but that may
547-
* very well never happen.)
548549
*/
549-
if (!var->isnull && var->datatype->typisarray)
550+
if (!var->isnull && var->datatype->typlen == -1)
550551
{
551552
if (VARATT_IS_EXTERNAL_EXPANDED_RW(DatumGetPointer(var->value)))
552553
{
@@ -561,7 +562,7 @@ plpgsql_exec_function(PLpgSQL_function *func, FunctionCallInfo fcinfo,
561562
{
562563
/* R/O pointer, keep it as-is until assigned to */
563564
}
564-
else
565+
else if (var->datatype->typisarray)
565566
{
566567
/* flat array, so force to expanded form */
567568
assign_simple_var(&estate, var,

0 commit comments

Comments
 (0)