Re: PQgetssl() and alternative SSL implementations - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: PQgetssl() and alternative SSL implementations
Date
Msg-id 20140819194717.GM16422@tamriel.snowman.net
Whole thread Raw
In response to Re: PQgetssl() and alternative SSL implementations  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: PQgetssl() and alternative SSL implementations  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
* Robert Haas (robertmhaas@gmail.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

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [patch] pg_copy - a command for reliable WAL archiving
Next
From: Josh Berkus
Date:
Subject: Re: [patch] pg_copy - a command for reliable WAL archiving