> 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.
That was me. The only other storage manager we had was the stable
memory storage manager, and that was just too confusing to the
developers. It can be easily added back by just changing the
DEFAULT_SMGR define to access the relation tuple. In fact, our code
uses the storage manager much more consistently now because to enable
multi-segment tables (>2 gigs for non-supporting OS's), we had to clean
that up.
> 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.
Yes, I think he needs that for foreign keys, and I think he wants to do
that for 6.6.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026