> > 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