I wrote:
> The cause of this failure is that parse_coerce.c thinks that a child
> table's rowtype is binary-compatible with its parent's rowtype:
> ...
> The Really Clean And Correct fix to this, IMHO, would be to invent a new
> expression node type that represents coercing a rowtype expression to a
> different rowtype. Execution of this node would disassemble and
> reassemble the tuple Datum, using code not too much different from
> execJunk.c, to produce the right column order and the right rowtype OID
> label. However that seems much too large a change for post-RC.
> (You could also argue that it requires an initdb, though I'd take the
> position that it doesn't because there are no working databases that
> would be affected.)
> A less clean but much more localized fix would be to cause ExecEvalExpr
> to do that work when it finds a RelabelType node whose output type is a
> composite type. (We could arrange to lookup the pg_type entry only once
> per query, during ExecInitExpr, so the performance hit on normal uses of
> RelabelType wouldn't be too bad.) A rough estimate is that this would
> require about 100 lines of new code in execQual.c, much of which could
> be adapted from other places.
I developed a patch based on the second approach, but eventually
realized that it doesn't quite close the gap. The problem is that there
are quite a few places that "know" that RelabelType is a run-time no-op
and feel free to ignore it. We could possibly hack each one to check
whether the result type is composite or not, but that seems unlikely to
provide a trustworthy fix. I now think that we don't really have any
choice but to go with the "clean" solution and represent rowtype
coercion as a new node type.
As I said above, I intend to treat this as a non-initdb-forcing change,
unless anyone vehemently objects.
regards, tom lane
