Re: PQgetssl() and alternative SSL implementations

On Tue, Aug 19, 2014 at 3:16 PM, Magnus Hagander <magnus@hagander.net> wrote:
> 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)

I think it's likely smarter to have totally separate functions.
First, to make it less likely that users will try to use a pointer to
one type of object as a pointer to some other kind of object.  And
second, because you might, for example, someday have an SSL
implementation that wants to return two pointers.  May as well make
that kind of thing easy.

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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company