From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Dave Page <dpage(at)vale-housing(dot)co(dot)uk>, pgsql-hackers(at)postgresql(dot)org, Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp> |
Subject: | Re: Practical impediment to supporting multiple SSL libraries |
Date: | 2006-04-13 18:17:07 |
Message-ID: | 28809.1144952227@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2006-04-13 19:29:41 | Re: Practical impediment to supporting multiple SSL libraries |
Previous Message | Greg Stark | 2006-04-13 17:37:58 | Re: Practical impediment to supporting multiple SSL libraries |