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
