This example in the regression database is a simplified version of a bug I was shown off-list:
regression=# select ( select q from ( select 1,2,3 where f1>0 union all select 4,5,6.0 where f1<=0 ) q ) from int4_tbl; ERROR: record type has not been registered The reason for the problem is that ExecEvalWholeRowVar is designed to bless the Var's record type (via assign_record_type_typmod) just once per query. That works fine, as long as the source tuple slot is the exact same TupleTableSlot throughout the query. But in the above example, we have an Append plan node for the UNION ALL, which will pass back its children's result slots directly --- so at the level where "q" is being evaluated, we see first the first leaf SELECT's output slot (which gets blessed) and then the second leaf SELECT's output slot (which doesn't). That leads to generating a composite Datum with typmod -1 ... oops. I can reproduce this bug in all active branches. Probably the reason it hasn't been identified long since is that in most scenarios the planner won't use a whole-row Var at all in cases like this, but will prefer to build RowExprs. (In particular, the inconsistent data types of the last sub-select output columns are necessary to trigger the bug in this example.) The easy fix is to move the blessing code from ExecEvalWholeRowVar into ExecEvalWholeRowFast. (ExecEvalWholeRowSlow doesn't need it since it doesn't deal with RECORD cases.) That'll add a usually-useless comparison or two per row cycle, which is unlikely to be measurable. A bigger-picture problem is that we have other once-per-query tests in ExecEvalWholeRowVar, and ExecEvalScalarVar too, whose validity should be questioned given this bug. I think they are all right, though, because those tests are concerned with validating the source rowtype, which should not change across Append children. The bug here is because we're assuming not just that the input rowtype is abstractly the same across all rows, but that the exact same TupleTableSlot is used to return every source row. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers