| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: PQgetssl() and alternative SSL implementations |
| Date: | 2014-08-19 23:24:44 |
| Message-ID: | 20140819232444.GB20476@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2014-08-19 19:11:46 -0400, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vladislav Sterzhanov | 2014-08-20 00:35:54 | KNN searches support for SP-GiST [GSOC'14] |
| Previous Message | Tom Lane | 2014-08-19 23:11:46 | Re: PQgetssl() and alternative SSL implementations |