Martijn van Oosterhout <kleptog@svana.org> writes:
> On Thu, Apr 13, 2006 at 11:14:57AM -0400, Greg Stark wrote:
> > That could be useful for applications but I think a driver really wants to
> > retain control of the flow of control. To make use of a callback it would
> > have
> > to have an awkward dance of calling whatever function gives libpq license to
> > call the callback, having the callback stuff the data in a temporary space,
> > then checking for new data in the temporary space, and returning it to the
> > user.
>
> We have an asyncronous interface. I was thinking like:
>
> sub mycallback(res,data)
> {
> /* stuff data in memory structure */
> if( row_count > 5 )
> gotenough = TRUE;
> }
>
> If you set non-blocking you can even go off and do other things while
> waiting. No need for temporary space...
>
> Does this seem too complex?
There's nothing wrong with a callback interface for applications. They can
generally have the callback function update the display or output to a file or
whatever they're planning to do with the data.
However drivers don't generally work that way. Drivers have functions like:
$q = prepare("select ...");
$q->execute();
while ($row = $q->fetch()) {
print $row->{column};
}
To handle that using a callback interface would require that $q->fetch invoke
some kind of pqCheckForData() which would upcall to the callback with the
available data. The callback would have to stuff the data somewhere. Then
fetch() would check to see if there was data there and return it to the user.
It's doable but dealing with this impedance mismatch between the interfaces
necessitates extra steps. That means extra copying and extra function calls.
--
greg
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
