Re: A successor for PQgetssl

Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> Do people like this idea?

Not really ...

> Note, I don't return a pointer to the GnuTLS session anywhere. I think
> that's a bad idea all round and we need to provide another way for
> programs to acheive the same effect.

No, failing to provide that is the bad idea, because then you're buying
into the notion that libpq will provide a universal API that will
incorporate anything anyone could possibly want to do with the
underlying SSL library. The above is *not* that, prima facie because
it is read-only access. Even if this was a feasible goal, it would absorb
a lot of time on our part that could be better spent elsewhere, plus a
lot of time on the part of app programmers rewriting existing
OpenSSL-aware or GnuTLS-aware code to instead use whatever random API we
tell them they ought to use. They have better things to do with their
time, too.

> I've got it almost completely working and have tested interoperability.
> ...
> - This breaks psqlODBC when it uses libpq because it wants to use OpenSSL
> and when libpq is compiled with GnuTLS that obviously won't work.

That alone is sufficient reason why we're not going down that path.
If we expose a GnuTLS-handle-fetching API then it's up to the ODBC
guys to extend their code to handle that SSL library when they feel
like it. But telling them that we're simply going to break their
code and not provide them a path to fix it is not happening.

regards, tom lane