On Fri, 2003-08-29 at 13:23, Tom Lane wrote: > Bruce Badger <[EMAIL PROTECTED]> 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. ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org