Karel Zak wrote:
I still don't see a big difference between DEALLOCATE and RESET -- both can break the JDBC driver.
You have to go out of your way to break the driver via DEALLOCATE, explicitly finding a statement name that the driver is using. There's also a reasonably simple fix: make the protocol-level and PREPARE/DEALLOCATE namespaces separate. There's been some discussion about doing this in the past.
In contrast RESET CONNECTION, by design, resets many things without needing to explicitly list them. The user could easily reset connection state that a driver is relying on without realizing it.
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.
That could work. It's a bit ugly, though, as currently drivers don't need to parse command status strings (unless they want an insert OID)
-O
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
