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.
Shouldn't these be default values set in postgresql.conf rather than copied settings inside the backend?
There is always a way to modify a GUC or to change the SET CONNECTION value (maybe a SELECT statement "SELECT change_value"). I have seen people doing that millions of time (I know, it is a bad idea).
Personally I'd expect a fully cleanup backend rather than a half-cleaned up backend. Setting two or three parameters when JDBC provides a recycled connection should not be a problem.
As far as prepared plans are concerned: There used to be a discussion about storing prepared plans accross connections (I recall even seeing some working code by Joe doing exactly that). It was rejected due to issues related to plan stability. This is exactly the same scenario now - keeping prepared plans actually means storing them accross "connection boundaries" (from a logical point of view it is a new connection - even is the backend is an old one).
If we want the behaviour proposed by JDBC we shouldn't call it RESET CONNECTION - maybe RESET STATUS or something like that). To me it is a totally different thing.
Best regards,
Hans
-- Cybertec Geschwinde u Schoenig Schoengrabern 134, A-2020 Hollabrunn, Austria Tel: +43/660/816 40 77 www.cybertec.at, www.postgresql.at
---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
