From: Magnus Hagander <mha@sollentuna.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@postgreSQL.org
To: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] Roadmap for FE/BE protocol redesign
Date: Mon, 10 Mar 2003 22:13:37 +0100
Message-ID: <81124B76C0CF364EBAC6CD213ABEDEF7509DA1@ARGON.edu.sollentuna.se> (raw)
> * Backend should pass its version number, database encoding,
> default client encoding, and possibly other data (any ideas?) to
> frontend during startup, to avoid need for explicit queries to get
> this info. We could also consider eliminating SET commands sent by
> libpq in favor of adding variable settings to startup packet's
> PGOPTIONS field. Ideally we could get back to the point where a
> standard connection startup takes only one packet in each
> direction.
How about a bitmap field of "additional features" supported by
client/backend that can be negotiated? (Doesn't have to be bitmap, of
course, but the idea..) That way the server (or client - doesn't matter
who goes first, I guess) could say "I support X and Y, but not Z and Q".
If the client supports both X and Y, both are enabled. If it supports
only X, then only X is enabled.
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. I also seem to recall there was some talk about on-wire
compression support - that would also be ideal for something like this.
I'm sure there can be more...
It should be easy to make it version-independent - just make both client
and server reject any "protocol features" that are unknown.
These are features that can be enabled/disabled in a backend/client of
the same version. It cannot (at least not easily) be handled with
protocol versioning, since you can have for example 7.4 with or without
SSL.
//Magnus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: mha@sollentuna.net, tgl@sss.pgh.pa.us, pgsql-hackers@postgreSQL.org
Subject: Re: [INTERFACES] Roadmap for FE/BE protocol redesign
In-Reply-To: <81124B76C0CF364EBAC6CD213ABEDEF7509DA1@ARGON.edu.sollentuna.se>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox