Fix mishandling of after-trigger state when a SQL function returns multiple

rows --- if the surrounding query queued any trigger events between the rows,
the events would be fired at the wrong time, leading to bizarre behavior.
Per report from Merlin Moncure.

This is a simple patch that should solve the problem fully in the back
branches, but in HEAD we also need to consider the possibility of queries
with RETURNING clauses.  Will look into a fix for that separately.

diff --git a/src/backend/executor/functions.c b/src/backend/executor/functions.c
index f3acc0a3060945f86956004535a8e95912eaac78..f18cb114300bddace2241345b46b99ccf048b16e 100644 (file)
--- a/src/backend/executor/functions.c
+++ b/src/backend/executor/functions.c
@@ -329,7 +329,14 @@ postquel_start(execution_state *es, SQLFunctionCachePtr fcache)
        /* Utility commands don't need Executor. */
        if (es->qd->operation != CMD_UTILITY)
        {
-               AfterTriggerBeginQuery();
+               /*
+                * Only set up to collect queued triggers if it's not a SELECT.
+                * This isn't just an optimization, but is necessary in case a SELECT
+                * returns multiple rows to caller --- we mustn't exit from the
+                * function execution with a stacked AfterTrigger level still active.
+                */
+               if (es->qd->operation != CMD_SELECT)
+                       AfterTriggerBeginQuery();
                ExecutorStart(es->qd, false);
        }
 
@@ -401,7 +408,8 @@ postquel_end(execution_state *es)
                {
                        ActiveSnapshot = es->qd->snapshot;
 
-                       AfterTriggerEndQuery(es->qd->estate);
+                       if (es->qd->operation != CMD_SELECT)
+                               AfterTriggerEndQuery(es->qd->estate);
                        ExecutorEnd(es->qd);
                }
                PG_CATCH();