| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Greg Stark <gsstark(at)mit(dot)edu>, 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 17:37:58 |
| Message-ID: | 87u08xgyvd.fsf@stark.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> So instead, you'd prefer to *always* store partial tuples in a temporary
> area, thereby making sure the independent-field-conversions case has
> performance just as bad as the dependent-conversions case.
> I can't follow that reasoning.
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.
All it sounded like to me was a need for a function that would wait until n
records were available (or perhaps n bytes worth of records) then return.
You seem to be talking about a much broader set of problems to solve.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-04-13 18:17:07 | Re: Practical impediment to supporting multiple SSL libraries |
| Previous Message | Martijn van Oosterhout | 2006-04-13 17:32:15 | Re: Practical impediment to supporting multiple SSL libraries |