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