Tom Lane wrote:
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.)
I've done this and it seems to work fine for the V3 protocol case.
However there are some callers of ProcessUtility that do not set ActivePortal: SPI and the SQL function code. These suffer from essentially the same problem as with the V3 protocol, for example:
test=# create function f1(text) returns void as $$
test$# declare c cursor for select * from pg_type where typname like $1;
test$# $$ language sql;
CREATE FUNCTION
test=# begin;
BEGIN
test=# select f1('%');
f1 ----
(1 row)
test=# fetch all from c; ERROR: no value found for parameter 1
SPI has a similar path via SPI_execp -> _SPI_execute_plan.
So it looks like I'll have to go back to passing a parameter list to ProcessUtility; even if we don't need to support the SPI/SQL function cases, it seems that ActivePortal is not guaranteed to point to the right parameter values.
-O
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
