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 > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
