Re: [HACKERS] [PATCHES] Implementing RESET CONNECTION ...
Christopher Kings-Lynne wrote: What would be absolutely ideal is a reset connection command, plus some way of knowing via the protocol if it's needed or not. And a way of notifying the client that a reset has happened. -O ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [PATCHES] Implementing RESET CONNECTION ...
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]
Re: [HACKERS] [PATCHES] Implementing RESET CONNECTION ...
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])
