On Tue, Aug 19, 2014 at 9:09 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@hagander.net> writes: >> On Tue, Aug 19, 2014 at 8:49 PM, Robert Haas <robertmh...@gmail.com> wrote: >>> 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. > > Robert's got a point though: there is always going to be somebody who > wants something we fail to expose. It's better to be able to say "well, > you can do PQgetssl and then munge it for yourself" than to have to say > "sorry, you're screwed". So if we're going to define PQgetssl as > returning NULL when you're not using OpenSSL, I don't see why we > shouldn't expose a similarly-defined PQgetXXX for each other underlying > implementation we support. There will not be that many of 'em, and > I suspect the people with very specific needs will not care about more > than one underlying library anyway. > > This does not say that we shouldn't also try to have some > library-independent functionality for interrogating certificate state > etc. Just that having an escape hatch isn't a bad thing.
I do agree tha thaving both would be useful. We could have something like int PQgetSSLstruct(void **sslstruct) which returns the type of struct. Then it's up to the application to know if it can handle it. For those apps that need a *lot*. But the basic attributes - something like the list from apache - should be retrievable in a library independent way. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers