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

> 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.

Yes, I agree this is a good way to do it.

> >>>> 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.

Agreed.

--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026