Re: Implementing RESET CONNECTION ...
От | Oliver Jowett |
---|---|
Тема | Re: Implementing RESET CONNECTION ... |
Дата | |
Msg-id | 41D9EF6C.4000502@opencloud.com обсуждение исходный текст |
Ответ на | Re: Implementing RESET CONNECTION ... (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Implementing RESET CONNECTION ...
|
Список | pgsql-patches |
Tom Lane wrote: > Kris Jurka <books@ejurka.com> writes: > >>Also I don't like the idea of cleaning up prepared statements. > > > Hmm. This seems a bit eye-of-the-beholder-ish, ie you could make a > legitimate argument either way. Maybe the RESET CONNECTION command > should have an option whether to zap prepared statements or not? That doesn't really help the JDBC driver case. The problem is that there are prepared statements that have been set up by the driver invisibly to the user. Zapping them will make the driver break, and it's too easy for the user code to do a full RESET CONNECTION and accidently zap them. Yes, you can break the JDBC driver currently by doing explicit DEALLOCATEs of its prepared statements -- but you have to do that quite deliberately so it's less of a problem. Having notification of either prepared statement deallocation or connection reset (a la ParameterStatus for GUC changes) would help the driver to recover from this case. -O
В списке pgsql-patches по дате отправления: