Re: [GENERAL] 7.3 Prepared statements

Barry Lind <blind@xythos.com>

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

Charles H. Woloszynski wrote:
> 
> 
> 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?
> 

There is no url argument currently.  There is a proposed patch that adds 
that functionality but it won't be there until 7.4.  As far as parsing 
the query looking for a semi colon that is probably what will be done 
for 7.4, but again that isn't there for 7.3.

The API call sets a member variable on the PreparedStatement object so 
once set it will remain set for that object until explicitly unset or 
the PreparedStatement is closed.

--Barry