> > X and Y? Well, the first thing that comes to mind is SSL > support. I'm > > not sure if it's still that way, but at least it used to be > a pretty > > ugly kludge there with the connection being dropped and > re-connected > > in some cases. > > SSL support is a bad example, since it would have to be > negotiated long before any more general-purpose negotiation > could occur. (You do want the connection authentication > exchange to happen under cover of SSL, no?) Certainly - it would be kind of stupid otherwise...
The idea was to make it possible to negotiate more than just SSL at this early stage (such as compression) in a more easy-to-maintain-backwards-compatibility way. Could be that only SSL needs to be enabled that early, and in that case having a generic mechanism in place to handle it would be unnecessary. > ISTM most of the other features you might want to turn on and > off can be handled as SET commands: the client tries to SET a > variable, the backend either accepts it or returns an error. > No need for special protocol support if you do it that way. > Can you point to any examples that have to have a special > protocol feature instead? Umm. Not really. I'm sure such a thing as compression could be enabled with "SET COMPRESSION=1" (as long as it's clearly defined when compression starts - e.g. after the server has sent it response, but before the next information is sent). The general idea was to make a framework there to make it easier to add something like that in the future. Something that came up when adding the SSL negotiation - since that was very kludgy to do with the current protocol. But again, if you foresee that no othe rfeatures will require negotiation at that early stage, it's probably overkill. //Magnus ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
