* Heikki Linnakangas (heikki@enterprisedb.com) wrote:
> 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?
Right.
> 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.
Eh, I figure it'll test the more common calls, though I agree that it
doesn't hit every symbol... Perhaps we should look at expanding the
regression tests to try and cover everything exported? That might
require a new binary if we don't want to clutter up psql, but it strikes
me as a pretty decent idea in general.
> 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.
I agree that this is certainly the best approach, if practical. Another
option would be to just check the symbol list using objdump. Sounds
like Tom already did something similar though by looking through the
exports file.
> 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)
Agreed.
Thanks,
Stephen
