Re: Practical impediment to supporting multiple SSL libraries - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Practical impediment to supporting multiple SSL libraries
Date
Msg-id 28809.1144952227@sss.pgh.pa.us
Whole thread Raw
In response to Re: Practical impediment to supporting multiple SSL libraries  (Greg Stark <gsstark@mit.edu>)
Responses Re: Practical impediment to supporting multiple SSL libraries  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> I think there's some confusion about what problem this is aiming to solve. I
> thought the primary problem ODBC and other drivers have is just that they want
> to be able to fetch whatever records are available instead of waiting for the
> entire query results to be ready.

No, that's not what I'm thinking about at all, and I don't think Martijn
is either.  The point here is that ODBC wants to store the resultset in
a considerably different format from what libpq natively provides, and
we'd like to avoid the conversion overhead.

Now, a callback function could be (ab)used for the purpose of not
waiting, very easily: either do real processing on each row for itself,
or signal the main app via some outside-the-API mechanism whenever it
has stored N rows.  The question the app author would have to ask
himself is whether he needs to undo that processing if the query fails
further on, and if so how to do that.  But that need not be our problem.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Practical impediment to supporting multiple SSL libraries
Next
From: Stephen Frost
Date:
Subject: Re: Practical impediment to supporting multiple SSL libraries