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 по дате отправления: