pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Greg Stark <gsstark@mit.edu>
To: Martijn van Oosterhout <kleptog@svana.org>
Cc: Greg Stark <gsstark@mit.edu>
Cc: Dave Page <dpage@vale-housing.co.uk>
Cc: pgsql-hackers@postgresql.org, Hiroshi Inoue <inoue@tpf.co.jp>
Subject: Re: Practical impediment to supporting multiple SSL libraries
Date: 13 Apr 2006 12:02:56 -0400
Message-ID: <87zmiph39r.fsf@stark.xeocode.com> (raw)
In-Reply-To: <20060413153220.GJ7362@svana.org>
References: <E7F85A1B5FF8D44C8A1AF6885BC9A0E4011C9C98@ratbert.vale-housing.co.uk>
	<20060413113405.GF7362@svana.org>
	<87ek01ik26.fsf@stark.xeocode.com>
	<20060413153220.GJ7362@svana.org>

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




view thread (81+ messages)  latest in thread

Message-ID: <87zmiph39r.fsf@stark.xeocode.com>
Permalink:  ../87zmiph39r.fsf@stark.xeocode.com/
Also on:    postgresql.org/message-id/87zmiph39r.fsf@stark.xeocode.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: gsstark@mit.edu, kleptog@svana.org, dpage@vale-housing.co.uk, inoue@tpf.co.jp
  Subject: Re: Practical impediment to supporting multiple SSL libraries
  In-Reply-To: <87zmiph39r.fsf@stark.xeocode.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox