Skip to content

Commit 543e5ab

Browse files
committed
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.
1 parent 1d058a2 commit 543e5ab

File tree

1 file changed

+1
-9
lines changed

1 file changed

+1
-9
lines changed

src/pl/plpgsql/src/pl_exec.c

Lines changed: 1 addition & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -1401,17 +1401,9 @@ exec_stmt_getdiag(PLpgSQL_execstate *estate, PLpgSQL_stmt_getdiag *stmt)
14011401
foreach(lc, stmt->diag_items)
14021402
{
14031403
PLpgSQL_diag_item *diag_item = (PLpgSQL_diag_item *) lfirst(lc);
1404-
PLpgSQL_datum *var;
1404+
PLpgSQL_datum *var = estate->datums[diag_item->target];
14051405
bool isnull = false;
14061406

1407-
if (diag_item->target <= 0)
1408-
continue;
1409-
1410-
var = estate->datums[diag_item->target];
1411-
1412-
if (var == NULL)
1413-
continue;
1414-
14151407
switch (diag_item->kind)
14161408
{
14171409
case PLPGSQL_GETDIAG_ROW_COUNT:

0 commit comments

Comments
 (0)