Re: PQgetssl() and alternative SSL implementations
От | Stephen Frost |
---|---|
Тема | Re: PQgetssl() and alternative SSL implementations |
Дата | |
Msg-id | 20140819194717.GM16422@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: PQgetssl() and alternative SSL implementations (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: PQgetssl() and alternative SSL implementations
|
Список | 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 по дате отправления: