Re: checking my understanding of TupleDesc

Hi,

On 2019-11-12 18:20:56 -0500, Tom Lane wrote:
> 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?

Yea, the stated reasoning is ExecTypeFromTL():
*
* Exception: if there are any dropped or missing columns, we punt and return
* NIL. Ideally we would like to handle these cases too. However this
* creates problems for ExecTypeFromTL, which may be asked to build a tupdesc
* for a tlist that includes vars of no-longer-existent types. In theory we
* could dig out the required info from the pg_attribute entries of the
* relation, but that data is not readily available to ExecTypeFromTL.
* For now, we don't apply the physical-tlist optimization when there are
* dropped cols.

I think the main problem is that we don't even have a convenient way to
identify that a targetlist expression is actually a dropped column, and
treat that differently. If we were to expand physical tlists to cover
dropped and missing columns, we'd need to be able to add error checks to
at least ExecInitExprRec, and to printtup_prepare_info().

I wonder if we could get away with making build_physical_tlist()
returning a TargetEntry for a Const instead of a Var for the dropped
columns? That'd contain enough information for tuple deforming to work
on higher query levels? Or perhaps we ought to invent a DroppedVar
node, that includes the type information? That'd make it trivial to
error out when such an expression is actually evaluated, and allow to
detect such columns. We already put Const nodes in some places like
that IIRC...

Greetings,

Andres Freund