Tom Lane wrote:
[... DECLARE with parameters failing ...]
>>Any chance of getting this fixed for 7.5?
>
>
> I'm up to my keister in PITR and nested-xact issues and won't have time
> to look at it soon. Do you want to take a look and see if you can find
> where the ball is getting dropped?
Here's what I've found so far:
The error occurs where it does because it is a DECLARE CURSOR WITH HOLD
outside an explicit transaction, so the resulting cursor is immediately
materialized when the implicit commit at end of statement happens. This
implicitly fetches all rows, and it's the fetch that fails.
When the DECLARE is enclosed in an explicit transaction, it succeeds,
but then subsequent FETCHes fail with the same error.
DECLARE -> PerformCursorOpen always passes NULL as a parameter list to
PortalStart() on the newly created portal, so no parameters are
available when executing it.
It seems like we should pass the original parameters from execution of
the DECLARE utility portal down through PortalRunUtility ->
ProcessUtility -> PerformCursorOpen, copy them into the newly created
portal's memory context, and pass the copies to PortalStart on the new
portal.
Does that sound about right?
-O
