Bruce Momjian gently chides:
> I wrote:
> > Sorry if this is a bit of a rant, but I really think we will have a much
> > better system if we understand what our system _is_ and try to extend it
> > in ways that make it better at that rather than to let it go all shapeless
> > and bloated with unrelated features and interfaces.
>
> I'll wait for this discussion to come down to earth, thanks. :-)
>
> Meaning, wow, that sounds nice, but sounds pretty hard too.
Really? Most of the data we need to collect is in the process table, or lock
manager data structure or could be added fairly readily.
So you need a few things:
- parser/planner needs to recognize the special tables and flag them in
the query plan. Easy way to do this is to store catalog and type info
for them in the normal places except that the tables table entry would
have a flag that says "I'm special", and maybe a function oid to the
actual iterator function (see next item).
The idea is that you rewrite the query "select * from procs" into
"select * from pg_pseudo_procs()".
- you then need an iterator function (returns next row per call) for each
fake table. This function reads the data from whatever the in memory
structure is and returns a tuple. That is, to the caller it looks a lot
like heapgetnext() or whatever we call that.
The rest of this, joins, projections, grouping, insert to another table etc
pretty much falls out of the basic functionality of the system for free.
-dg
David Gould dg@illustra.com 510.628.3783 or 510.305.9468
Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612
"Don't worry about people stealing your ideas. If your ideas are any
good, you'll have to ram them down people's throats." -- Howard Aiken