Re: [JDBC] V3 protocol + DECLARE problems

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [JDBC] V3 protocol + DECLARE problems
Date: 2004-07-25 06:37:52
Message-ID: 41035540.9020608@opencloud.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-jdbc

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2004-07-25 10:35:51 Re: Planning for beta (was Re: Sketch of extending error handling
Previous Message Alvaro Herrera 2004-07-25 04:34:31 resowner.c $PostgreSQL$

Browse pgsql-jdbc by date

  From Date Subject
Next Message cby_y 2004-07-26 07:34:31 questions
Previous Message Oliver Jowett 2004-07-24 00:11:34 Re: JDBC memory usage