* Greg Stark (gsstark@mit.edu) wrote:
> Tom Lane <tgl@sss.pgh.pa.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.
Honestly, I think that may be part of it but it seems they're more
interested in storing the tuples in their own structure right away
instead of keeping a PQresult around and using it everywhere.
> 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.
I'm not sure that you'd actually want to block until there was a certain
amount returned, but that would be doable I suppose.
> You seem to be talking about a much broader set of problems to solve.
I'd like to improve the API in general to cover a set of use-cases that
I've run into quite a few times (and apparently some others have too as
other DBs offer a similar API). I'd also like the ODBC driver to be
able to use libpq instead of having its own implementation of the
wireline protocol. I was hoping these would overlap but it's possible
they won't in which case it might be sensible to add two new metheds to
the API (though I'm sure to get flak about that idea).
Thanks,
Stephen