| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Chapman Flack <chap(at)anastigmatix(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: checking my understanding of TupleDesc |
| Date: | 2019-11-12 23:20:56 |
| Message-ID: | 30691.1573600856@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2019-11-12 17:39:20 -0500, Tom Lane wrote:
>> There's a semi-exception, which is that the planner might decide that we
>> can skip a projection step for the output of a table scan node, in which
>> case dropped columns would be included in its output. But that would only
>> be true if there are upper plan nodes that are doing some projections of
>> their own. The final query output will definitely not have them.
> I *think* we don't even do that, because build_physical_tlist() bails
> out if there's a dropped (or missing) column.
Ah, right. Probably because we need to insist on every column of an
execution-time tupdesc having a valid atttypid ... although I wonder,
is that really necessary?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2019-11-12 23:21:53 | Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index. |
| Previous Message | Tom Lane | 2019-11-12 23:15:28 | Re: make pg_attribute_noreturn() work for msvc? |