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 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Reply via email to