Re: PQgetssl() and alternative SSL implementations - Mailing list pgsql-hackers

From Andres Freund
Subject Re: PQgetssl() and alternative SSL implementations
Date
Msg-id 20140819232444.GB20476@awork2.anarazel.de
Whole thread Raw
In response to Re: PQgetssl() and alternative SSL implementations  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2014-08-19 19:11:46 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2014-08-20 00:58:22 +0300, Heikki Linnakangas wrote:
> >> I don't much like adding a separate function for every SSL implementation,
> >> but you've got a point that it would be nice to make it difficult to call
> >> PQgetSSLstruct() and just assume that the returned struct is e.g an OpenSSL
> >> struct, while it's actually something else. Perhaps:
> 
> > A good reason to not have functions with the respective functions is
> > that it requires either including the relevant headers or adding forward
> > declarations of the libraries type.
> 
> It requires no such thing.  What we do for PQgetssl() is declare it as
> returning "void *", and we could easily do the same for other libraries.

Well, the reason the library specific variant has been called superiour
upthread is the potential for type safety...

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PQgetssl() and alternative SSL implementations
Next
From: Vladislav Sterzhanov
Date:
Subject: KNN searches support for SP-GiST [GSOC'14]