* Martijn van Oosterhout (kleptog@svana.org) wrote: > Why not? Internally we call pqAddTuple for every tuple, calling a user > function instead is hardly going to be more expensive. Also, I was > thinking of the situation where the user function could set a flag > so the eventual caller of (perhaps) PQconsumeInput knows that it's got > enough for now.
I went ahead and looked through the libpq source a bit. What I was
suggesting looks like it would change primairly getAnotherTuple to,
instead of allocating the result memory itself, just store the result
into the appropriate place in the user-provided memory space. Thus,
getAnotherTuple wouldn't do any allocation and wouldn't call pqAddTuple
at all. It would need to keep track of where it is in the user-provided
memory area and if it runs out of space return back through the
'outofmemory' mechanism.
The new function would basically set up the appropriate structures in
the PGconn and then call 'parseInput()' which would then handle any
recently-arrived data, call getAnotherTuple, which would then detect
that it's dumping data into a user-provided area and would do so until
it's finished being called by parseInput() or it runs out of user memory
space. This would be used with the async command processing.
A drawback, of course, is that this degenerates to busy-waiting if the
application has nothing better to do. Any clue as to if the PQsocket
could safely be used in a select()-based system? I'm guessing it could,
just never tried that myself. :) Also not sure how to know if there's
data which needs to be sent and hasn't been yet for some reason.
Thanks!
Stephen
signature.asc
Description: Digital signature
