Andres Freund <and...@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