Kris Jurka <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
