Re: [GENERAL] 7.3 Prepared statements

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