Bruce Momjian wrote:
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.
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

Also, let me mention PHP uses connection pooling and wants to use RESET

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,


Cybertec Geschwinde u Schoenig
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +43/660/816 40 77,

---------------------------(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

Reply via email to