From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | chris(at)bitmead(dot)com, "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Re: [SQL] Re: [GENERAL] Proposed Changes to PostgreSQL |
Date: | 2000-02-03 03:58:41 |
Message-ID: | 200002030358.WAA03721@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers pgsql-sql |
> 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Stephane FILLON | 2000-02-03 03:59:10 | RE: [GENERAL] PL/pgSQL syntax/usage question |
Previous Message | Chris Bitmead | 2000-02-03 03:57:12 | Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2000-02-03 04:02:44 | Re: [SQL] Proposed Changes to PostgreSQL |
Previous Message | Chris Bitmead | 2000-02-03 03:57:12 | Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2000-02-03 04:02:44 | Re: [SQL] Proposed Changes to PostgreSQL |
Previous Message | Chris Bitmead | 2000-02-03 03:57:12 | Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL |