Re: Practical impediment to supporting multiple SSL libraries
От | Tom Lane |
---|---|
Тема | Re: Practical impediment to supporting multiple SSL libraries |
Дата | |
Msg-id | 28809.1144952227@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Practical impediment to supporting multiple SSL libraries (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: Practical impediment to supporting multiple SSL libraries
|
Список | 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 по дате отправления: