On Tuesday 25 March 2003 1:13 pm, Darko Prenosil wrote:
> How about sharing connections between sender and receiver. After all
> 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
> which Sender will post results to which Receiver ?
I understand why the PQsendQuery and PQgetResult won't work across
connections, so that's not an issue.
> The only way to have sender and receiver on different connections is to
> write some kind of own server that will connect server and receiver to
> "Pair", but I did newer heard for such "construction" in SQL server
> philosophy.
>
> It is also possible to store the "results" from Sender to tables, and
> Receiver can periodically check if something happened and get the results!
Yes - that's what I intend doing with the LISTEN and NOTIFY - I will have a
Trigger StoredProc that will be called when a table is updated in response to
the Sender issuing a request. The Trigger StoredProc will then insert an
entry in another table that will result in a notification.
I've separated out the logic of insertion into the notification table into a
Trigger StoredProc because its not really part of the logic of updating our
schema tables - effectively the notification table is meta-data to help the
Receiver determine what has been changed.
I just think this is a little clunky and was hoping for something cleaner ...
> That is true, but why do you wish to send another query if you send them
> all in one PQSendQuery ?
Our architecture is message based, so I can't delay the Sender waiting for
incoming messages (buffering them together) into a single PQsendQuery because
its all asynchronous communication.
> Unfortunately RAISE NOTICE can only function through same connection, and
> if You insist on different connection, this will not help.
Again, thanks for the heads-up on this!
Damien