On Mon, Aug 02, 1999 at 10:25:15PM -0400, Bruce Momjian wrote:
>
> Sounds interesting, and doable. People have asked from time to time
> about this. Our access routines are very modular, so if you can get
> your stuff working inside the tuple access routines, you will have it
> made. The easiest way may be to just hack up the storage manager
> (smgr). Create a new access method, and hook your remote stuff to that.
>
I considered two quick and dirty proof-of-concept implementations first:
hacking the smgr, and upgrading functions to allow them to return sets,
then building views with an ON SELECT rule that fired an arbitrary db
access routine.
One advantage of going the smgr route is I automagically get all the
buffer and relation caching that's builit-in. A negative is that it
basically just gives me a remote table: every query's going to pull
the whole table, or I'm going to have to write somewhat hairy access
methods, I think. I think it's a little _too_ low level. I want to be
able to have the backend DB do as much work as possible, minimizing the
expensive network transfer.
Oh, and BTW, while the smgr infrastructure is still in place, and all
accesses vector through it, the relsmgr field has been removed from
the pg_class table, and all calls to smgropen() and friends use the
DEFAULT_SMGR #define.
The second, having functions return sets, is still a possibility, but it
suffers from the same lack of extensibility - I only get complete tables
back. Even worse, I don't get the buffer caches for free. If rules
_currently_ could return sets, it's be a 1-2 day hack to get something
working.
So, I think I'll see what Jan has to say about subselect RTEs, as Tom
suggested. Seems the way to go for future work.
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
