Re: A successor for PQgetssl

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > I have to agree with Martijn here too.  It's not all that expensive to
> > provide read/write calls to abstract away the specific library being
> > used (since psqlODBC, at least, couldn't care less which library is
> > being used, really)
>
> You're failing to consider async applications.  AFAICS, the *minimum*

You're assuming I intended just 'read()' and 'write()', I suppose I
should have been more explicit but I certainly understand there's more
than just read() and write() involved, though not by much.  I'm not sure
I see a reason we wouldn't just use the existing PQsocket() for the same
socket back to the user for select()-based systems (don't we do this for
SSL-enabled connections too anyway?)...  There's not a whole lot special
when it comes to handling data transport, or much that has changed
lately or is likely to change anytime soon.

> consumed any caffeine yet today...).  And that's just considering
> the data transport aspect of it.  I'm still concerned that SSL-using
> apps may wish to twiddle the SSL library in ways we don't even know
> about.

SSL is all about the certificates, really.  As long as we provide
that back to the user in a library-agnostic way they'll be able to
do whatever they like with it, such as compare it to a CRL or use OCSP
to check the current status.  Of course, these are usually things you're
more concerned about on the *server* side, which we don't currently
support anyway.  With supporting multiple SSL libraries we'll have to
deal with these issues on the *server* side, should we decide to
implement them someday (which would be nice...) anyway so trying to
play like we don't want to or don't care to know about them doesn't
really work.  Just saying we won't do CRLs or OCSP ever would just mean
we don't get run in some environments.

Of course, in either case we can play the "if you want it, write the
code" card but I'd really expect to get complaints from admins who want
to use X.509 but need CRL/OCSP support before getting complaints from
application developers that they need libpq to provide something more
for them...
Thanks,
    Stephen