Re: [GENERAL] 7.3 Prepared statements
От | Charles H. Woloszynski |
---|---|
Тема | Re: [GENERAL] 7.3 Prepared statements |
Дата | |
Msg-id | 3E15EA36.3040206@clearmetrix.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] 7.3 Prepared statements (Barry Lind <blind@xythos.com>) |
Ответы |
Re: [GENERAL] 7.3 Prepared statements
|
Список | pgsql-jdbc |
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
В списке pgsql-jdbc по дате отправления: