Hans-Jürgen Schönig wrote: > I completely agree with Karel. I think it is a bad idea to change the > protocol for such a minor feature - i tend to call it overkill. > I want to add one point to this discussion: There is not just JDBC - > other connection pools or clients might want different behaviour (which > can from my point of view only lead to a complete reset). > > If the JDBC driver prefers different behaviour (maybe for prepared > statements) we should discuss further options for RESET. > Now there is: RESET CONNECTION (cleaning entire connection), RESET ALL > (cleaning GUCS only) and RESET some_guc. > Maybe we want RESET LISTENER, RESET PREPARED, RESET CURSORS. > Personally I think this is not a good idea.
I think autocommit is a good example for comparison. One big problem was that some users had autocommit in their server configs on startup and that caused scripts to fail. I don't imagine anyone would add RESET CONNECTION in their startup script. However, I can imagine someone doing RESET CONNECTION from JDBC and the interface should continue working. Should we add something like SET CONNECTION that would set the reset values for RESET CONNECTION? JDBC could then use SET CONNECTION and then any RESET CONNECTION would reset back to that point. RESET has a similar capability where when you RESET you reset to the connection defaults, not to the defaults from postgresql.conf. Also, let me mention PHP uses connection pooling and wants to use RESET CONNECTION too. -- Bruce Momjian | http://candle.pha.pa.us email@example.com | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match