Tom Lane wrote:
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.
It doesn't seem too weird, we're using Parse/Bind to separate the query template from concrete parameter values. When the Bind is done, we want to behave as if executing the DECLARE with actual parameter values substituted into the query string originally -- that matches the behaviour of Bind for other queries. So using the parameters to DECLARE for the constructed portal seems right.
If we were to do it any other way, we'd have to special-case Parse or Bind for DECLARE to expect some different (zero?) number of parameters in the Bind. exec_bind_message does a check quite early on that the number of parameters provided matches the number expected.
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.)
Ok, I'll do that.
-O
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
