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
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073