From 65b2f93b587be67ea1d5e4d98a99599937aa7b19 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Mon, 14 Aug 2006 22:57:15 +0000 Subject: Fix oversight in initial implementation of PORTAL_ONE_RETURNING mode: we cannot assume that there's exactly one Query in the Portal, as we can for ONE_SELECT mode, because non-SELECT queries might have extra queries added during rule rewrites. Fix things up so that we'll use ONE_RETURNING mode when a Portal contains one primary (canSetTag) query and that query has a RETURNING list. This appears to be a second showstopper reason for running the Portal to completion before we start to hand anything back --- we want to be sure that the rule-added queries get run too. --- src/include/utils/portal.h | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) (limited to 'src/include/utils/portal.h') diff --git a/src/include/utils/portal.h b/src/include/utils/portal.h index 3f308f5f58..92cc55189e 100644 --- a/src/include/utils/portal.h +++ b/src/include/utils/portal.h @@ -39,7 +39,7 @@ * Portions Copyright (c) 1996-2006, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California * - * $PostgreSQL: pgsql/src/include/utils/portal.h,v 1.65 2006/08/12 02:52:06 tgl Exp $ + * $PostgreSQL: pgsql/src/include/utils/portal.h,v 1.66 2006/08/14 22:57:15 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -63,10 +63,13 @@ * tuplestore for access after transaction completion). * * PORTAL_ONE_RETURNING: the portal contains a single INSERT/UPDATE/DELETE - * query with a RETURNING clause. On first execution, we run the statement - * and dump its results into the portal tuplestore; the results are then - * returned to the client as demanded. (We can't support suspension of - * the query partway through, because the AFTER TRIGGER code can't cope.) + * query with a RETURNING clause (plus possibly auxiliary queries added by + * rule rewriting). On first execution, we run the portal to completion + * and dump the primary query's results into the portal tuplestore; the + * results are then returned to the client as demanded. (We can't support + * suspension of the query partway through, because the AFTER TRIGGER code + * can't cope, and also because we don't want to risk failing to execute + * all the auxiliary queries.) * * PORTAL_UTIL_SELECT: the portal contains a utility statement that returns * a SELECT-like result (for example, EXPLAIN or SHOW). On first execution, @@ -187,6 +190,7 @@ typedef struct PortalData */ #define PortalGetQueryDesc(portal) ((portal)->queryDesc) #define PortalGetHeapMemory(portal) ((portal)->heap) +#define PortalGetPrimaryQuery(portal) PortalListGetPrimaryQuery((portal)->parseTrees) /* Prototypes for functions in utils/mmgr/portalmem.c */ @@ -215,6 +219,7 @@ extern void PortalDefineQuery(Portal portal, List *parseTrees, List *planTrees, MemoryContext queryContext); +extern Query *PortalListGetPrimaryQuery(List *parseTrees); extern void PortalCreateHoldStore(Portal portal); #endif /* PORTAL_H */ -- cgit v1.2.1