> 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. ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
