I wrote:
> (Wanders away wondering just how much the regression tests exercise
> holdable cursors.)
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.
After a little bit of thought I'm not sure it's even possible to
reproduce this problem with libpq, because it doesn't expose any way to
issue a bare protocol Execute command against a pre-existing portal.
(I had thought psqlOBC went through libpq, but maybe it's playing some
games here.)
Anyway, I'm thinking the appropriate fix might be like this
- CurrentResourceOwner = portal->resowner;
+ if (portal->resowner)
+ CurrentResourceOwner = portal->resowner;
in several places in pquery.c; that is, keep using
TopTransactionResourceOwner if the portal doesn't have its own.
A more general but probably much more invasive solution would be to fake
up an intermediate portal when pulling data from a held portal, to
more closely approximate the explicit-FETCH case.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
