Re: [SQL] Re: [GENERAL] Proposed Changes to PostgreSQL

Bruce Momjian <pgman@candle.pha.pa.us> writes:
>>>> So the field is created on the fly to show what table it came from.
>>>> Seems like a good idea, though implementing another usually-invisible
>>>> column will be tough.
>> 
>> What problems do you forsee?

> Well, it is usually pretty strange to carry around a column that doesn't
> exist through all the code and finally contruct it at the end.  I would
> suspect something in the rewrite system could do that pretty easily,
> though.  That is the direction I would go with that.

Yeah.  In fact, since the field is not required except on specific
user request (explicit SELECT, or if you like Chris' SET SHOW_CLASSNAME
idea, that'd still get translated into a SELECT target item at some
pretty early stage), I don't see any need for it to get added to the
HeapTupleHeader fields.  That makes the implementation a *lot* cleaner
because you wouldn't need in-memory HeapTupleHeader to be different from
on-disk headers.  I'm visualizing this as a parameterless function (or
maybe a new primitive expression node type) that gets evaluated during
ExecProject's construction of the output tuple for a a bottom-level
seqscan or indexscan plan node.  The only trick is to persuade the
planner to push it down to the bottom level; normally anything that
isn't a Var gets evaluated at the top of the plan tree.

>>>> This bothers me.  We return relational data, showing the same number of
>>>> columns and types for every query.  I don't think we want to change
>>>> that, even for OO. 

My thought also.  If we had a *real* object orientation, then a returned
column would have an abstract data type that might correspond to an
object supertype.  Of course that just pushes the problem down a level:
how does the application know what methods the returned object has?
How can it even invoke those methods --- whatever code might exist
for them would live on the server, presumably, not get shipped around
in query results.
        regards, tom lane