> I saw your message on the postgresql mailing lists. The TelegraphCQ
> project at Berkeley is implemented using the Postgres code base as a
> starting point. TelegraphCQ has a generalized mechanism for receiving
> data from remote data sources, and also for on demand request-response
> style queries to remote data sources. You can get more information
>about the project at: http://telegraph.cs.berkeley.edu. A quick
>overview of the remote data source features can be found here:
>http://telegraph.cs.berkeley.edu/telegraphcq/v0.2/Data_Acquisition.html
> I am currently doing preliminary investigations to see how difficult
>it would be to integrate access to remote data sources into the
>postgres code base.
Thank you very much for this information! I'll definitely take a look at
it.
> There is a project in the contrib directory called dblink which may
>fit your needs.
Well, I saw it but although it can serve the communication between
db-nodes, it seems it may not be appropriate for what I want to do. Even
though it can be used to send queries and receive results, it blocks
until a transaction is finished (at least I think so). This may be no
problem for other applications but for a mediator-wrapper model with
adaptive/dynamic query processing techniques it is. For example, if it
really blocks (and thats why I asked about concurrent SPI calls & fork)
it is not possible to have multiple queries on wire or monitor the
connection (e.g. data rate etc.).
Excuse me if I make a mistake in what I say above, I'm not the best
programmer :-) !!
Best Regards,
Ntinos Katsaros
PS: Sorry if this mail comes to you for the second time Owen. I have
problems with my SMTP server.