Re: [GENERAL] 7.3 Prepared statements

Поиск
Список
Период
Сортировка
От Barry Lind
Тема Re: [GENERAL] 7.3 Prepared statements
Дата
Msg-id 3E15EE51.1090403@xythos.com
обсуждение исходный текст
Ответ на Re: [GENERAL] 7.3 Prepared statements  ("Charles H. Woloszynski" <chw@clearmetrix.com>)
Список pgsql-jdbc

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




В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Aaron Mulder
Дата:
Сообщение: Patch so Pooled Connections are PGConnections
Следующее
От: "Charles H. Woloszynski"
Дата:
Сообщение: Re: [PERFORM] join over 12 tables takes 3 secs to plan