Andres Freund writes:
> On 2019-11-12 18:20:56 -0500, Tom Lane wrote:
>> 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?
> Yea, the stated reasoning is ExecTypeFromTL():
> [
Hi,
On 2019-11-12 18:20:56 -0500, Tom Lane wrote:
> Andres Freund 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
Andres Freund 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 onl
Hi,
On 2019-11-12 17:39:20 -0500, Tom Lane wrote:
> > and under what other
> > circumstances one would only encounter 'cleaned up' TupleDescs with
> > no dropped attributes, and contiguous numbers for the real ones?
>
> I don't believe we ever include dropped columns in a projectio
Chapman Flack writes:
> On 09/29/19 20:13, Chapman Flack wrote:
>> From looking around the code, I've made these tentative observations
>> about TupleDescs:
>>
>> 1. If the TupleDesc was obtained straight from the relcache for some
>> relation, then all of its attributes should have nonzero attre
On 09/29/19 20:13, Chapman Flack wrote:
> From looking around the code, I've made these tentative observations
> about TupleDescs:
>
> 1. If the TupleDesc was obtained straight from the relcache for some
>relation, then all of its attributes should have nonzero attrelid
>identifying that r
