Skip site navigation (1) Skip section navigation (2)

Re: [INTERFACES] Roadmap for FE/BE protocol redesign

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgreSQL(dot)org>,<pgsql-interfaces(at)postgreSQL(dot)org>
Subject: Re: [INTERFACES] Roadmap for FE/BE protocol redesign
Date: 2003-03-10 21:13:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-interfaces
> * 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



pgsql-hackers by date

Next:From: Tom LaneDate: 2003-03-10 21:19:42
Subject: Re: [GENERAL] division by zero
Previous:From: Tom LaneDate: 2003-03-10 21:07:23
Subject: Making FETCH more spec-compliant

pgsql-interfaces by date

Next:From: Tom LaneDate: 2003-03-10 21:26:24
Subject: Re: [INTERFACES] Roadmap for FE/BE protocol redesign
Previous:From: Roberto CostaDate: 2003-03-10 21:10:33
Subject: Automatic detection of PostgreSQL version

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group