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.
Regards,
Hans
Karel Zak wrote:
> 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
>
--
Cybertec Geschwinde u Schoenig
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +43/660/816 40 77
www.cybertec.at, www.postgresql.at