Re: NOT EXIST for PREPARE
От | Vladimir Sitnikov |
---|---|
Тема | Re: NOT EXIST for PREPARE |
Дата | |
Msg-id | CAB=Je-EdhePiDx_ke-EzmAyUnxAHiMip99YttqsO8fYzKyYU3Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: NOT EXIST for PREPARE (Merlin Moncure <mmoncure@gmail.com>) |
Ответы |
Re: NOT EXIST for PREPARE
(Merlin Moncure <mmoncure@gmail.com>)
|
Список | pgsql-hackers |
Merlin>proposed would allow use of server side prepared statements with JDBC. It would not. If we discuss end-to-end scenarios in detail, we would end up with "send full query on each execution" -> lex/gram on each execution kind of overheads. That is hardly a proper way of using prepared statements. I'm not eager to merge half-a-solution to pgjdbc. Just in case: I'm one of those who maintain pgjdbc. Merlin>https://pgbouncer.github.io/faq.html#how-to-use-prepared-statements-with-session-pooling pgbouncer's docs> the reset query must clean old prepared statements I'm afraid, that is just "you must clean prepared statements". Where are the issues/suggestions from pgbouncer team? I'm just a year into pgjdbc, I've attended a couple of the largest PostgreSQL conferences (like 700+ attendees), however I know of exactly 0 suggestions on improving the matter. Everybody just keeps saying "discard all". Merlin>With proposed, the application can simply prepare after Merlin>opening the 'connection' and not have to worry about handling the Merlin>error or scope. Can you name at least a couple of applications that indeed "prepare after opening the connection"? Note: it is not something JDBC driver can do. That "prepare after opening" requires cooperation from the application. I'm afraid, I know exactly 0 such applications. At least, in java world. Applications typically use framework generated queries, so it would be hard to impossible to "simply prepare after opening". The "set of used sql queries" is likely to be infinite even for a single application. That is sad, but true. That is exactly the reason why I've implemented _transparent_ statement cache for pgjdbc. As application is using generated queries, pgjdbc detects query reuse and enables server-prepared queries behind the scenes. If no one objects, I would just go ahead and file "report ParameterStatus(pgbouncer.backend_id=...)" issue for pgbouncer. I guess we can agree on the name and semantics of the new status message, so it would not accidentally collide with the one of newer PG version. Merlin>Although there was a very long standing issue where jdbc Merlin>would try to prepare 'BEGIN' in such a a way that it could not be Merlin>disabled -- that was fixed. What bothers me is current pgjdbc CI has exactly 0 pgbouncer tests. That means "BEGIN is fixed" can easily break and no one would notice that. It is tracked under https://github.com/pgjdbc/pgjdbc/issues/509, so if there's interest in pgbouncer vs pgjdbc, then #509 might be a good start. Vladimir
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Tom LaneДата:
Сообщение: Re: PostgreSQL 9.6 behavior change with set returning (funct).*