Martijn van Oosterhout <kleptog@svana.org> writes: > 1. Changing it to always return (void*), irrespective of SSL > ... > Personally, I'm in favour of 1, because then we can get rid of the > #include for openssl, so users don't have to have openssl headers > installed to compile postgresql programs.
I like that too. I've never been very happy about having libpq-fe.h depending on USE_SSL. There is a more serious issue here though: if we allow more than one SSL library, what exactly can an application safely do with the returned pointer? It strikes me as very dangerous for the app to assume it knows which SSL library is underneath libpq. It's not at all hard to imagine an app getting an OpenSSL struct pointer and trying to pass it to GnuTLS or vice versa. To the extent that there are apps out there that depend on doing something with this function, I think that even contemplating supporting multiple SSL libraries is a threat. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend