Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit534d0ea

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. Previouslythis happened only for expanded arrays, but that was a result ofsloppy thinking. (If the plpgsql function did not end by returningthe object, the result would be to leak the object until thesurrounding 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 dohere to make plpgsql work efficiently with expanded objects thataren't arrays, but this is an easy first step.Discussion:https://postgr.es/m/CACxu=vJaKFNsYxooSnW1wEgsAO5u_v1XYBacfVJ14wgJV_PYeg@mail.gmail.com
1 parent67bab53 commit534d0ea

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+
elseif (var->datatype->typisarray)
565566
{
566567
/* flat array, so force to expanded form */
567568
assign_simple_var(&estate,var,

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp