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