Re: [GENERAL] 7.3 Prepared statements

Charles H. Woloszynski <chw@clearmetrix.com>

From: "Charles H. Woloszynski" <chw@clearmetrix.com>
To: Barry Lind <blind@xythos.com>
Cc: PostgreSQL jdbc list <pgsql-jdbc@postgresql.org>
Date: 2003-01-03T19:53:26Z
Lists: pgsql-general

Barry Lind wrote:

> The implementation in the current driver is such that you need to 
> enable the use of server side prepare on a statement by statement 
> basis (default is not to use it).  So you should only enable if for 
> those statements for which it will work.  To illustrate the problem 
> here is an example:
>
> pstat = conn.prepareStatement("insert into foo values (?); update bar 
> set y = ?;);
>
> When run in server prepared mode this will issue the following 
> statements to the server:
>
> prepare abc(int, int) as insert into foo values ($1); update bar set y 
> = ($2);
>
> which will fail since the prepare statement is ended by the first 
> semicolon.  So this would be an example of a JDBC prepared statement 
> that works fine currently but would fail when used with server side 
> prepared statements.

Is the driver's mode set using a URL argument or an API call?  I thought 
I saw mention of a URL argument.  Is the API call something that 
persists between connection uses?  We use a connection pool and I want 
to get the right semantics for the use of this feature.  

Personally, I'd prefer that the server scan for a non-quoted semicolon 
and revert to non-prepared' operation.  The cost of the extra scan is 
likely to be minimal and would allow those folks who use a connection 
pool to use this feature and have it work when it can and not interfere 
when it might.  I am guessing that you may have already parsed the 
statement looking for ?'s  

If so, wouldn't the supression of the 'prepare' be relatively 
straight-forward?

Charlie


-- 


Charles H. Woloszynski

ClearMetrix, Inc.
115 Research Drive
Bethlehem, PA 18015

tel: 610-419-2210 x400
fax: 240-371-3256
web: www.clearmetrix.com