Re: FE/BE Protocol - Specific version - Mailing list pgsql-hackers

From Bruce Badger
Subject Re: FE/BE Protocol - Specific version
Date
Msg-id 1062167867.24075.13.camel@wally
Whole thread Raw
In response to Re: FE/BE Protocol - Specific version  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: FE/BE Protocol - Specific version
Re: FE/BE Protocol - Specific version
Re: FE/BE Protocol - Specific version
List pgsql-hackers
On Fri, 2003-08-29 at 23:35, Tom Lane wrote:
> Rod Taylor <rbt@rbt.ca> writes:
> >> So, being able to stop connections trying to use old protocol versions
> >> would be very helpful in this case.
> 
> > Wouldn't it be better to have StORE run a select version() after
> > connecting?
> 
> Well, his point is that old versions of his client code wouldn't know to
> do that.  However, I don't think that what he's suggesting is a suitable
> answer either --- he wants to rely on a chance coincidence, namely that
> we're upgrading the FE/BE protocol at the same time that he wants to
> make an incompatible application-level change.

Exactly right.  I made a mistake and this is a chance to fix it. 
Really, just that simple.
> What I'd do, if I wanted to lock out old clients from accessing
> particular tables, is just rename the tables to something else.
> (Or keep using the same names, but put the tables in a schema or
> database that old clients won't look in.)  The clients wouldn't fail
> very gracefully, perhaps, but the protocol-level hack doesn't qualify
> as graceful in my book either ...

I don't think that there is a graceful way to fix this.  Unless I can
pull off the "blocking old protocol versions" trick, it seems that the
most likely option will come from another chance coincidence, i.e. that
the StORE schema changes.

Unfortunately, I am not in a position to initiate a change in the StORE
schema.  StORE is also used with other RDBMSs, and the users of those
have no incentive to bless a change in the schema just to help out the
PostgreSQL users.

So, if it did come to pass that rejecting connections on the basis of
protocol version was possible, then I could fix the broken encoding
implementation.  Otherwise, I think I'll have to wait for the next
chance coincidence.

... unless anyone has any better ideas? :-/

All the best,Bruce



pgsql-hackers by date:

Previous
From: Robert Treat
Date:
Subject: Re: [GENERAL] before trigger problem
Next
From: Bruce Badger
Date:
Subject: Re: FE/BE Protocol - Specific version