Andres Freund <andres@anarazel.de> 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():
> [ ExecTypeFromTL needs to see subexpressions with valid data types ]
> 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...
Yeah, a DroppedVar thing might not be a bad idea, it could substitute
for the dummy null constants we currently use. Note that an interesting
property of such a node is that it doesn't actually *have* a type.
A dropped column might be of a type that's been dropped too (and,
if memory serves, we reset the column's atttypid to zero anyway).
What we'd have to do is excavate atttyplen and attalign from the
pg_attribute entry and store those in the DroppedVar node. Then,
anything reconstructing a tupdesc would have to use those fields
and avoid a pg_type lookup.
I'm not sure whether the execution-time behavior of such a node
ought to be "throw error" or just "return NULL". The precedent
of the dummy constants suggests the latter. What would error out
is anything that wants to extract an actual type OID from the
expression.
regards, tom lane