Re: [JDBC] V3 protocol + DECLARE problems
От | Oliver Jowett |
---|---|
Тема | Re: [JDBC] V3 protocol + DECLARE problems |
Дата | |
Msg-id | 41035540.9020608@opencloud.com обсуждение исходный текст |
Ответ на | Re: [JDBC] V3 protocol + DECLARE problems (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: