Gregory Stark wrote:
> What we want to know is that things like pgadmin can connect properly to
> either 8.3, 8.2, and even 8.1 using the new libraries regardless of how the
> server authentication is configured. Do they work correctly if the server
> tries to do password authentication, ident, kerberos, etc.
That's a matter of protocol-compatibility, and that's not the issue
here. We're talking about *ABI* compatibility. In a nutshell, if you
have a an program that's compiled with 8.2 libpq-library, will it work
when linked to 8.3 library at runtime? And if you have a program
compiled with 8.3 library, does it work with a 8.2 library?
But yeah, the regression tests won't help much with that. I suppose you
could try to use an 8.2 psql with an 8.3 library and see if it works,
but I don't know how much of the library interface psql exercises.
I think it's easier and more reliable to just go through the commit logs
for libpq, and see if anything has changed. Even that isn't bullet-proof
though. For example, if there's an incompatible change to a struct or a
typedef that's used as a function parameter, that breaks binary
compatibility as well.
In the future, we should try to keep this in mind during the development
cycle, and bump the minor version number the first time a
backwards-compatible change, like adding a new function, is made, and
bump the major version number the first time an incompatible change is
made. Like we do for catalog version, except that we only want to bump
the libpq version number once per release. (though we do sometimes
forget to bump the catalog version number as well)
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
