Fix GET DIAGNOSTICS for case of assignment to function's first variable.

An incorrect and entirely unnecessary "safety check" in exec_stmt_getdiag()
caused the code to treat an assignment to a variable with dno zero as a
no-op.  Unfortunately, that's a perfectly valid dno.  This has been broken
since GET DIAGNOSTICS was invented.  It's not terribly surprising that the
bug went unnoticed for so long, since in most cases you probably wouldn't
use the function's first-created variable (normally its first parameter)
as a GET DIAGNOSTICS target.  Nonetheless, it's broken.  Per bug #6551
from Adam Buraczewski.

diff --git a/src/pl/plpgsql/src/pl_exec.c b/src/pl/plpgsql/src/pl_exec.c
index 2ad4bed0b6d310c9e7bbb091b1829f2c40b3f673..7f911b8771009686b91b0e029e4848939a727124 100644 (file)
--- a/src/pl/plpgsql/src/pl_exec.c
+++ b/src/pl/plpgsql/src/pl_exec.c
@@ -1430,17 +1430,9 @@ exec_stmt_getdiag(PLpgSQL_execstate *estate, PLpgSQL_stmt_getdiag *stmt)
        foreach(lc, stmt->diag_items)
        {
                PLpgSQL_diag_item *diag_item = (PLpgSQL_diag_item *) lfirst(lc);
-               PLpgSQL_datum *var;
+               PLpgSQL_datum *var = estate->datums[diag_item->target];
                bool            isnull = false;
 
-               if (diag_item->target <= 0)
-                       continue;
-
-               var = estate->datums[diag_item->target];
-
-               if (var == NULL)
-                       continue;
-
                switch (diag_item->kind)
                {
                        case PLPGSQL_GETDIAG_ROW_COUNT: