* Greg Stark (gsstark@mit.edu) wrote:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
> > 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.
>
> So how would you provide the data to the callback? And how does having a
> callback instead of a regular downcall give you any more flexibility in how
> you present the data?
The callback can be called for each record without having to store any
more than 1 tuple's worth of information in libpq. I suppose you could
change things such that a call using the new interface only processes 1
tuple worth from the input stream instead and just not read any more
data from the socket until there have been enough calls to process
tuples. That's really more the double-memory issue though. There's
also the double-copying that's happening and the have to to wait for all
the data to come in before being able to read it, of course that last
could be handled by cursors...
Thanks,
Stephen
