On Tue, Aug 19, 2014 at 8:49 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Aug 18, 2014 at 7:54 AM, Heikki Linnakangas > <hlinnakan...@vmware.com> wrote: >> In order to support alternatives to OpenSSL, we need to wean off >> applications from using PQgetssl(). To do that, we have to provide an >> alternative API to get the same information. PQgetSSL() returns a pointer >> directly to the OpenSSL private struct, and you can do anything with that. >> We cannot have a generic interface that exposes everything, so we need to >> identify the information that people actually want, and expose that. > > I have a hard time believing that something like this will really > satisfy anyone. Why not just add PQgetSchannelHandleOrWhatever() and > call it good? We can try to be incredibly thorough in exposing the > information people want and we will still inevitably miss something > that someone cares about; worse, we'll spend an awful lot of time and > energy along the way.
Well, for one you push the full burden onto the application. Then every application has to support every SSL library we do, even for the simplest check. And it has to be built against the same one. (So for example if someone wants to use openssl on windows - yes there might still be reasons for that even if we support schannel - they have to rebuild every one of their applications. And every one of their higher level language drivers sitting on top of openssl). The same problem of course appears on say Linux, if you end up using a mix of openssl and gnutls or a mix of nss and openssl for example. It's not likely to happen as long as you only use the officially built packages, but you're likely in for quite a bit of pain if you are using any non-standard packaging like the oneclick installers etc. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers