Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6])
	by hub.org (8.9.2/8.9.1) with ESMTP id KAA88220
	for <pgsql-interfaces@postgreSQL.org>;
	Fri, 12 Feb 1999 10:19:29 -0500 (EST)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA24831;
	Fri, 12 Feb 1999 10:18:52 -0500 (EST)
To: Matthew Hagerty <matthew@venux.net>
cc: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] Example of Asynchronous Query Processing in C? 
In-reply-to: Your message of Thu, 11 Feb 1999 22:56:03 -0500
	<4.1.19990211224527.009502e0@mail.venux.net>
Date: Fri, 12 Feb 1999 10:18:52 -0500
Message-ID: <24829.918832732@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Matthew Hagerty <matthew@venux.net> writes:
> I was reading through the docs for libpq and in the Asynchronous Query
> Processing section there is mention of an example program that demonstrates
> the use of select(2) to wait for the backend.  I could not find the
> example, does anyone have one?

Hmm, it does promise one doesn't it?  What I was actually intending to
do was just modify the second sample program to wait for a NOTIFY with
select() rather than sleep().  But I forgot :-(

As I was explaining to someone else recently, a reasonable sample
program for async query processing is hard to come up with.  The only
reason you'd do it is because your app has something else it needs to
do concurrently, which is tough to demonstrate in a simple program.

The actual use of select() is not hard --- you can use pqWait() in
interfaces/libpq/fe-misc.c as an example.  The issue that's hard to
show in a small program is what sort of control structure all this
is likely to be embedded in.

> What I am hoping to accomplish is to have my frontend accept a query, pass
> it to the backend, and build the output based on the query.  I would also
> like the user to be able to limit the number of records (tuples) returned
> and cancel the query if necessary; hence the use of the async functions and
> select(2).

Limiting the tuple count will be a feature in 6.5 but is not really
possible without backend support.  As for cancel, if you can issue the
cancel from a signal handler like psql does, you don't really need the
async query interface ...

			regards, tom lane