Oliver Jowett <[EMAIL PROTECTED]> writes:
> 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?
Hm. The copying bit bothers me, and I guess after some thought it's
a semantic issue. If you've got
DECLARE c CURSOR FOR SELECT ... WHERE foo = $1;
FETCH 10 FROM c;
it's not very clear when the value of $1 should be supplied. With your
proposal the parameter value would have to be supplied in the Bind
message for the DECLARE CURSOR command. That may be the only way to do
it (certainly I'd not want several successive FETCHes to use different
parameter values), but it still seems a bit weird.
BTW, rather than hacking the parameter list of ProcessUtility,
I'd be inclined to just look at ActivePortal->portalParams in
PerformCursorOpen. (Come to think of it, we could also copy
ActivePortal's sourceText at the PortalDefineQuery step.)
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
