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

Tue, 11 Mar 2003 10:21:17 +0100
"Magnus Hagander" <mha@sollentuna.net>
Re: [INTERFACES] Roadmap for FE/BE protocol redesign 
"Magnus Hagander" <mha@sollentuna.net> writes:
> 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.

I can't think of anything except compression that could be interesting
at that early stage, so I'm not seeing a reason to invent a general
negotiation mechanism.  Even if we thought we needed one, we don't have
a lot of flexibility at that stage of the game, because neither side yet
knows what version the other is, and so assuming that the other side
knows of the mechanism is bogus.  The existing method for requesting SSL
is a tad klugy, granted, but I'm not sure we can do any better for
transport-option negotiation.

			regards, tom lane

Tue, 11 Mar 2003 09:50:25 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [INTERFACES] Roadmap for FE/BE protocol redesign 