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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
