Content-Type: text/plain;
  charset="iso-8859-2"
From: Darko Prenosil <darko.prenosil@finteh.hr>
To: Damien Dougan <damien.dougan@mobilecohesion.com>,
	pgsql-interfaces@postgresql.org
Subject: Re: Asynchronous Communication across two independent components
Date: Tue, 25 Mar 2003 13:13:25 +0000
User-Agent: KMail/1.4.1
References: <200303241535.25156.damien.dougan@mobilecohesion.com>
	<200303242127.01355.darko.prenosil@finteh.hr>
	<200303250915.48917.damien.dougan@mobilecohesion.com>
In-Reply-To: <200303250915.48917.damien.dougan@mobilecohesion.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200303251313.25238.darko.prenosil@finteh.hr>

On Tuesday 25 March 2003 09:15, Damien Dougan wrote:
> Darko,
>
> Thanks for the response, but I'm not sure if your suggestions will meet my
> needs - as the page you referenced seems to suggest that these operations
> must all go over the same connection (and I have a Sender and a Receiver =
on
> separate connections).
>
How about sharing connections between sender and receiver. After all=20
PGConnection is only pointer that can be same for Sender and Receiver.
How do you mean to connect Sender and Receiver ? How should postgres know=
=20
which Sender will post results to which Receiver ?

The only way to have sender and receiver on different connections is to wri=
te=20
some kind of own server that will connect server and receiver to "Pair", bu=
t=20
I did newer heard for such "construction" in SQL server philosophy.

 It is also possible to store the "results" from Sender to tables, and=20
Receiver can periodically check if something happened and get the results!

It all seems a little fuzzy to me. Maybe You can explain it with more detai=
ls.

> Some comments embedded below ...
>
> On Monday 24 March 2003 9:27 pm, you wrote:
> > You can send whole bunch of SQL commands using PQsendQuery, not only one
> > ! After that you can get more than one PGResults depending on what
> > commands you send to Postgres. You only need to terminate it with ";".
> > For example:
> > PQSendQuery("SELECT * FROM pg_table; BEGIN TRANSACTION; DELETE FROM tbl
> > WHERE id =3D 1; COMMIT;");
> > When PQSendQuery command is executed, queries are just send to server.
> > Non-blocking means: program will not block and wait for results to come
> > !!! After that you should use combination of PQconsumeInput, PQisBusy a=
nd
> > PQgetResult. You can even cancel rest of the queries with
> > PQrequestCancel. It is all explained at:
> > http://developer.postgresql.org/docs/postgres/libpq-async.html , and it
> > works perfectly (spiking from my experience) !!!
>
> I did have a read through this before posting - and I was hoping the above
> mechanisms would do the trick for me - but there appears to be two proble=
ms
> with the PQsendQuery and PQgetResult.
>
> (1) You cannot call PQsendQuery on the same connection until PQgetResult
> has returned null.

That is true, but why do you wish to send another query if you send them al=
l=20
in one PQSendQuery ?

>
> (2) You cannot call PQgetResult on a different connection from PQsendQuery
> to obtain the results of a query.
>
> So whilst your solution would be fine for asynchronous comms within a
> single connection, I'm afraid its not what I'm looking for!
>
> > If You need to wait to see if first command passes, and then send
> > another, threads and non-blocking commands can't help You! Then You
> > simple must execute with PQExec and wait for result !
> >
> > > I also looked at the LISTEN/NOTIFY, which seemed promising. However,
> > > there does not appear to be any mechanism to identify the event that
> > > caused the notification. I was hoping to be able to have the Receiver
> > > handle the notification by going to the appropriate relation and
> > > picking up the data which was now ready for it - but there's no way to
> > > know which entry it is!
> >
> > You can RAISE NOTICE inside of the function("stored procedure") with
> > custom text. But You do not need this. PQsendQuery with multiple sql
> > commands is what you need !
>
> Thanks for the RAISE NOTICE heads-up - I'll take a look at this.
>
Unfortunately RAISE NOTICE can only function through same connection, and i=
f=20
You insist on different connection, this will not help.


> Damien
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html