Brett McCormick <brett@work.chicken.org> writes:
> [ Brett was unpleasantly surprised to find major changes in libpq ]
Sorry about that, Brett. This was discussed on the hackers list a month
or so ago, but evidently you missed the thread. I made some fairly
major changes in the client-side libpq to allow it to be used
asychronously, that is without blocking until the completion of a query.
I didn't bother to do much cleanup of the backend side, since it didn't
have to change to get the functionality I was after. I agree that it
could stand a cleanup, so if you want to do it, by all means do.
> it would appear that libpq now has a outgoing data buffer associated
> with PGconn struct which only gets sent (with send()!?) when pqFlush
> gets called. the backend still appears to use and pass FILE * for
> reading and writing. I wasn't aware that you can read data from a
> FILE * sent with send() over a socket. Is this portable?
Yes. Data on a connection is data; there's no way for the far end to
tell what syscall or library was used to collect and send the data.
(The far end might not even be Unix or C based, after all.)
> In any case, I don't think this bodes well for my SSL patch -- and I
> think I've missed something -- why have we switched to send/recv?
Because going through the stdio library gives up control over blocking
when no data is available. getc() will block, period.
Does SSL support non-blocking recv? If so it shouldn't be hard to put
an SSL layer under what I did with libpq. Note the existence of
PQsocket() however. If an SSL connection can't be select()'d for then
we have got trouble.
BTW, I believe I did fix your earlier complaint that the backend called
pq_putstr again after closing the client connection.
regards, tom lane