PGSQL internals question...

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

inside the backend, if I have a TupleTableSlot, can I find out from what
basetable it is referring to or not?

Since it's not necessarily referring to any table at all, the general
answer is "no". Do you have a reason to assume that the slot is
holding a tuple directly fetched from disk, rather than constructed
on-the-fly?

regards, tom lane

Tom Lane wrote:

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

inside the backend, if I have a TupleTableSlot, can I find out from what
basetable it is referring to or not?

Since it's not necessarily referring to any table at all, the general
answer is "no". Do you have a reason to assume that the slot is
holding a tuple directly fetched from disk, rather than constructed
on-the-fly?

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?

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?

Chris Bitmead <chrisb@nimrod.itg.telstra.com.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

Tom Lane wrote:

It's not clear to me why you think that ExecProject has anything to
do with the problem...

Only that it calls things like ExecEvalExpr which evaluates different
types of column expressions. I was thinking I would need a T_classoid,
or T_magicColumn expression type evaluated there which grabs the
classoid from somewhere.

I doubt that routine will change at all.
I'd be inclined to look at the handling of "system" attributes such
as OID.

Except that oid really exists in the db right? The only thing special
about oid compared to any other attribute is that it isn't expanded by
"*", which doesn't seem like that much difference.

Probably you'd need to add a source-table-OID field to
HeapTupleData, which XXXScan would need to fill in,

Wouldn't ExecTargetList need access to this HeapTupleData instance? Does
it?

and then there's
have to be code to pull it out again when the right system attribute
number is referenced.

Would a non-existant attribute have a system attribute number? Where do
you suggest this code should be that "pulls it out"?

-----Original Message-----
From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
Behalf Of Chris Bitmead

Would a non-existant attribute have a system attribute number? Where do
you suggest this code should be that "pulls it out"?

CTID has a system attribute number SelfItemPointerAttributeNumber(-1).
Different from other system attributes it corresponds to an item(t_self)
in HeapTupleData not to an item(t_ctid) in HeapTupleHeaderData.
Please look at include/access/htup.h.
Probably heap_xxxx() functions in access/heap/heapam.c would have
to fill in the new system attribute.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp