Re: Implementing RESET CONNECTION ...
Karel Zak <zakkr@zf.jcu.cz>
From: Karel Zak <zakkr@zf.jcu.cz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Oliver Jowett <oliver@opencloud.com>, Kris Jurka <books@ejurka.com>, Hans-Jürgen Schönig <postgres@cybertec.at>, eg@cybertec.at, List pgsql-patches <pgsql-patches@postgreSQL.org>
Date: 2005-01-04T08:08:40Z
Lists: pgsql-hackers
On Mon, 2005-01-03 at 20:27 -0500, Tom Lane wrote: > I'm inclined to think that we'd have to add a protocol message that > reports RESET CONNECTION to really answer objections of this type. > That seems to bring the thing into the category of "stuff that forces > a protocol version bump" :-( > > Perhaps RESET CONNECTION should be a protocol-level operation instead > of a SQL command? That would prevent user-level code from causing it > without the driver knowing. I still don't see a big difference between DEALLOCATE and RESET -- both can break the JDBC driver. I'm not sure if we need prevent bad usage of PG tools (JDBC in this case). The DEALLOCATE/RESET usage is under user's full control and everything can be described in docs. I think each PG command returns some status. For example in libpq it's possible check by PQcmdStatus(). I think JDBC can checks this status (by own PQcmdStatus() implementation) and if PG returns string "CONNECTION- RESETED" it can deallocate internal stuff. This solution doesn't require touch the protocol. Karel -- Karel Zak <zakkr@zf.jcu.cz>