On Fri, 2003-08-29 at 23:35, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
