Hello PostgreSQL hackers -
I'm considering trying to implement a new feature that would have some
interesting possible uses. I'm wondering how difficult it would be
to implement a table who's content does not come out of the files on
disk, but instead is accessed remotely from another database? Absolutely
insane, or just mad-scientist insane? I need this to solve a subset of
the class of problems that Cohera (Stonebraker's latest commercial db)
is aimed at, but I don't need all the functionality provided by that
(nor the 4-5 figure price tag!)
An initial proof of concept could be done via 'ON SELECT' rules, if 'C'
functions could return result sets, instead of just a single complex type
(row).
A more complete solution would need to let the optimizer know about
remote tables, and allow for things like sending of sub-sections of
queries where all the tables involved are on the same remote server, etc.
The problem I'm hoping to solve involves merging two adminstratively
independent databases that contain similar, but not identical, data. This
would allow queries to run against both backends, but the appplication
would only see one data source.
It occurs to me that this would be useful for people who would like
to access more than one db on the same postgresql server from a single
frontend, or for distributing a db across a Beowulf cluster, perhaps.
So, am I completely nuts, or is this a possibility?
Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005
