On 2013-04-10 19:29:06 -0400, Tom Lane wrote:
> Andres Freund <and...@2ndquadrant.com> writes:
> > On 2013-04-10 19:06:12 -0400, Tom Lane wrote:
> >> And the answer is they're not testing this code path at all, because if
> >> you do
> >> DECLARE c CURSOR WITH HOLD FOR ...
> >> FETCH ALL FROM c;
> >> then the second query executes with a portal (and resource owner)
> >> created to execute the FETCH command, not directly on the held portal.
>
> > But in that path CurrentResourceOwner gets reset to portal->resowner as
> > well (see PortalRunFetch())?
>
> Right, but that's the FETCH's portal, which is a regular "live" portal
> that has a ResOwner.
I don't think so?
standard_ProcessUtility:
PerformPortalFetch:
/* get the portal from the portal name */
portal = GetPortalByName(stmt->portalname);
...
/* Do it */
nprocessed = PortalRunFetch(portal,
stmt->direction,
stmt->howMany,
dest);
PortalRunFetch:
PG_TRY();
{
ActivePortal = portal;
CurrentResourceOwner = portal->resowner;
So it seems to trigger a very similar codepath?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
