| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(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: | 2015-01-28 17:04:45 |
| Message-ID: | 32652.1422464685@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> What bothers me about this is that it punts SSL work to the application
> and requires that they be coded to work with both OpenSSL and whatever
> else we implement (eg: GnuTLS) to do anything but the most simple
> checks. That's a problem because people are *not* going to want to
> #include both OpenSSL and GnuTLS headers into their applications because
> they don't know which PG will be compiled with.. Not to mention that
> it'd be darn awkward to do so.
The point of this is to provide an escape hatch for people who really
want to do XYZ even though we provide no API for XYZ in libpq. Hopefully,
those people will be few and far between, because anything that's a really
common requirement should be catered for by libpq.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2015-01-28 17:09:47 | Re: Sequence Access Method WIP |
| Previous Message | Stephen Frost | 2015-01-28 16:58:47 | Re: PQgetssl() and alternative SSL implementations |