(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
