Re: PQgetssl() and alternative SSL implementations

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> BTW, if we're beating on libpq, I wonder if we shouldn't consider
> bumping the soversion at some point. I mean, I know that we
> technically don't need to do that if we're only *adding* functions and
> not changing any of the existing stuff in backward-incompatible ways,
> but we might *want* to make some backward-incompatible changes at some
> point, and I think there's a decent argument that any patch in this
> are is already doing that at least to PQgetSSL(). Maybe this would be
> a good time to think if there's anything else we want to do that
> would, either by itself or in combination, justify a bump.

I'm not a big fan of doing it for this specific item, though it's
technically an API breakage (which means we should actually have
libpq2-dev packages, make everything that build-deps on libpq-dev
update to build-dep on libpq2-dev, have libpq6, etc..). If there are
other backwards-incompatible things we wish to do, then I agree that
it'd be good to do them all at the same time (perhaps in conjunction
with 10.0...). This is the part where I wish we had been keeping an
updated list of things we want to change (like on the wiki..).

It's certainly not a fun transistion to go through. I also wonder if
we're going to need to worry about what happens when libpq5 and libpq6
end up linked into the same running application. I don't think we
have any symbol versioning or anything to address that risk in place..

Thanks,

Stephen