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
