Re: PGSQL internals question...

Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au> writes:
> I'm looking at implementing classoid and I was looking around inside
> ExecProject, wondering if this would be a good place to create the
> magical classoid field. If I understand ExecProject it takes some "real"
> tables and mangles them into a single result tuple. Do I know if it is a
> tuple direct from disk? It seemed that way, but perhaps you can tell me?

ExecProject is used for any plan node that has to generate an output
tuple that's not identical to its input ... which means almost
anything except Sort or Unique or some such. You can't assume that
the input's straight off of disk, it could easily be the result of
a lower-level join.

> The other approach I'm looking at is to add a Relation field to
> TupleTableSlot which is populated inside of XXXScan or whatever, which
> can be lifted out inside ExecProject. Do you think I'm on the right
> track?

It's not clear to me why you think that ExecProject has anything to
do with the problem... I doubt that routine will change at all.
I'd be inclined to look at the handling of "system" attributes such
as OID. Probably you'd need to add a source-table-OID field to
HeapTupleData, which XXXScan would need to fill in, and then there's
have to be code to pull it out again when the right system attribute
number is referenced.

regards, tom lane