Just out of curiosity. It may look like a bit of a hack, but as long as
it is
clearly documented, it seems doable:
>
> > How about sharing connections between sender and receiver. After all
> > PGConnection is only pointer that can be same for Sender and
Receiver.
Yes, share connection by a common PGconn data set, write/read via a
binary file
or whatever interprocess data exchange you prefer.
> > How do you mean to connect Sender and Receiver ? How should postgres
know
> > which Sender will post results to which Receiver ?
That's not the point as I understand it. There is one sender using
PQsendQuery,
and one receiver using PQgetResult. So postgres does not even need to
know
there are two processes working as sender resp. receiver.
>
> 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.
>
Really? Before making a call to PQsendQuery you have to make sure the
previous
results have been completely processed by PQgetResult. So you need some
kind of
interprocess communication facility anyway to tell the sender when
another
PQsendQuery is possible. And as long as there is no ok from the
receiver, the
sender has to accumulate the queries.
Does this sound plausible or did I get something completely wrong?
Regards, Christoph
