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
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
