What would be absolutely ideal is a reset connection command, plus some
way of knowing via the protocol if it's needed or not.
Chris
Bruce Momjian wrote:
What did we decide on RESET CONNECTION. Do we want an SQL command or
something only the protocol can do?
---------------------------------------------------------------------------
Oliver Jowett wrote:
(cc'ing -hackers)
Karel Zak wrote:
I think command status is common and nice feedback for client. I think
it's more simple change something in JDBC than change protocol that is
shared between more tools.
There is a bit of a queue of changes that would be nice to have but
require a protocol version change. If we're going to change the protocol
for any of those we might as well handle RESET CONNECTION cleanly too.
We need some common way how detect on client what's happen on server --
a way that doesn't mean change protocol always when we add some
feature/command to backend. The command status is possible use for this.
Command status only works if commands are directly executed. If you can
execute the command indirectly, e.g. via a PL, then you'll miss the
notification. Making RESET a top-level-only command isn't unreasonable,
but using command status won't work as a general approach for notifying
clients.
We have a mechanism for GUC changes that uses a separate message
(ParameterStatus). Perhaps that should be generalized to report
different sorts of connection-related changes.
-O
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
