On Tue, Aug 19, 2014 at 9:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Tue, Aug 19, 2014 at 8:49 PM, Robert Haas <robertmhaas@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 HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
