Re: A successor for PQgetssl

On Mon, Apr 17, 2006 at 11:25:26AM -0400, Tom Lane wrote:
> You're failing to consider async applications. AFAICS, the *minimum*
> API would be
> read
> write
> read ready?
> write ready?
> get socket so I can use it in select()

Actually, you only need two functions:

read
write

The "get socket" already exists as PQsocket().

Both SSL libraries work perfectly fine if the user sets the connection
to non-blocking via PQsetnonblocking(). They just return -EAGAIN. I was
actually thinking of the two functions as follows:

typedef PostgresPollingStatusType pq_read_func( PGconn *conn, void *buf, int *len);
typedef PostgresPollingStatusType pq_write_func( PGconn *conn, const void *buf, int *len);

The existing PostgresPollingStatusType seems to handle both blocking
and non-blocking states just fine.

> (very possibly there's some stuff I missed, considering I haven't
> 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.

Well, I checked a few libs like libcurl and libldap. They generally
allow you to configure the files containing the certificates but that's
about it.

Seriously, if people want to do really sophisticated things with the
SSL library, they should setup s_tunnel instead. If we wanted to let
users control everything we'd allow Anonymous DH key transfers. The
README.SSL lists the situations were SSL makes sense and if you fall
outside of that you shouldn't be using SSL.

All I'm asking for is that libpq be made SSL-library *agnostic* so that
users like psqlODBC can just *use* the connection with having to jump
through hoops.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)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.