From: | Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: PGSQL internals question... |
Date: | 2000-06-23 06:44:55 |
Message-ID: | 39530767.E66AE3B6@nimrod.itg.telecom.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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"?
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 2000-06-23 08:35:53 | RE: PGSQL internals question... |
Previous Message | Tom Lane | 2000-06-23 06:19:24 | Re: PGSQL internals question... |