Re: FE/BE Protocol - Specific version

From: Bruce Badger <bruce_badger(at)badgerse(dot)com>
To: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FE/BE Protocol - Specific version
Date: 2003-08-29 04:18:40
Message-ID: 1062130721.19547.104.camel@wally
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2003-08-29 at 13:23, Tom Lane wrote:
> Bruce Badger <bruce_badger(at)badgerse(dot)com> writes:
> > Will it be possible to tell a PostgreSQL back end to use *only* the new
> > version of the FE/BE protocol?
> > That is, will it be possible to set up a database that will reject
> > connection attempts that do not use the new protocol version?
>
> I cannot imagine a reason that that would be a good idea ... but
> convince me if you can ...

Well, I'm asking because of a specific application.

StORE is a version control system for VisualWorks Smalltalk. PostgreSQL
is often the chosen back end for StORE. There are many publicly
accessible StORE repositories running on PostgreSQL.

The StORE to PostgreSQL mapping code currently encodes Byte arrays using
Base64, and stores them in bytea fields. It should not have happened
like this, but it did - my fault, a stop-gap got used before the gap was
properly filled.

I would like to migrate to using escaped byte arrays in a new version of
the StORE->PostgreSQL mapping software, but we have to be able to
accommodate the mixture of old and new databases, and old and new client
libraries.

I would prefer to have each StORE database have only one encoding used
throughout. So "old" databases would still use Base64, and "new"
databases would use escaped strings. The new databases will contain an
additional table indicating the version of the StORE mapping library
they were created by, and this will enable newer implementations to use
the correct encoding in any given situation. The old mapping library,
of course, will just keep on trying to use the old Base64 encoding.

As the new FE/BE protocol is not supported by the "old" mapping library,
we could stop old versions of the library getting confused (and perhaps
corrupting) "new" databases by setting new databases to refuse
connections using old FE/BE protocol version.

So, being able to stop connections trying to use old protocol versions
would be very helpful in this case.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message scott.marlowe 2003-08-29 04:28:21 Re: Nasty problem in hash indexes
Previous Message Curt Sampson 2003-08-29 03:29:14 Re: Bumping block size to 16K on FreeBSD...