Re: Practical impediment to supporting multiple SSL libraries

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

In response to

Responses

Browse pgsql-hackers by date

  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