Re: A successor for PQgetssl

On Sun, Apr 16, 2006 at 05:29:04PM -0400, Tom Lane wrote:
> 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

The intention is not to provide access to everything. If people want to
know more about the certificate, we simply export the certificate to
them and they can do with it what they like, including sending it to
another program. I wasn't expecting that list to grow much because
there's not much to export.

Besides, what's wrong with read-only access? What parameters were you
expecting them to want to change? After a session is setup there are no
parameters to change anymore. All you need is read and write.

> 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.

The whole point is that app writers should not be aware at all which
library we're using. At the moment psqlODBC requires openssl because we
force them to. They only use three OpenSSL functions, SSL_read,
SSL_write, and SSL_get_error.

If we provided a hook to allow people read/write directly, they
wouldn't need to know about the SSL connection at all. I think that's a
much better way to go than adding a new library specific function for
every little feature we add.

You objected to this on the grounds of a problem with the COPY
functions, except I can't see any problem that's relevent. The problem
with copy was that data didn't have a length. Given the user is sending
their own packets, we always have a length.

> > - 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.

By going down this path you're saying that psql will never be able
display the cipher of an SSL connection if the libpq was compiled with
a different library. If we provide a read/write than psqlODBC can
remove code and it will work with GnuTLS. Isn't that much better?

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.