Skip to content

Commit f318ee8

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 5bd06e6 commit f318ee8

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
@@ -1430,17 +1430,9 @@ exec_stmt_getdiag(PLpgSQL_execstate *estate, PLpgSQL_stmt_getdiag *stmt)
14301430
foreach(lc, stmt->diag_items)
14311431
{
14321432
PLpgSQL_diag_item *diag_item = (PLpgSQL_diag_item *) lfirst(lc);
1433-
PLpgSQL_datum *var;
1433+
PLpgSQL_datum *var = estate->datums[diag_item->target];
14341434
bool isnull = false;
14351435

1436-
if (diag_item->target <= 0)
1437-
continue;
1438-
1439-
var = estate->datums[diag_item->target];
1440-
1441-
if (var == NULL)
1442-
continue;
1443-
14441436
switch (diag_item->kind)
14451437
{
14461438
case PLPGSQL_GETDIAG_ROW_COUNT:

0 commit comments

Comments
 (0)