From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgreSQL(dot)org>, <pgsql-interfaces(at)postgreSQL(dot)org> |
Subject: | Re: [INTERFACES] Roadmap for FE/BE protocol redesign |
Date: | 2003-03-11 09:21:17 |
Message-ID: | 81124B76C0CF364EBAC6CD213ABEDEF71D316F@ARGON.edu.sollentuna.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-interfaces |
> > 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
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2003-03-11 09:22:18 | Re: Roadmap for FE/BE protocol redesign |
Previous Message | Christoph Haller | 2003-03-11 09:09:11 | gmake -C regress check failure |
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2003-03-11 09:22:18 | Re: Roadmap for FE/BE protocol redesign |
Previous Message | Justin Clift | 2003-03-11 07:24:24 | Re: Roadmap for FE/BE protocol redesign |