I wrote:
> The issue seems to be that given a construct like
> ARRAY[
> ROW('1.2.2'::semver, '='::text, '1.2.2'::semver),
> ROW('1.2.23', '=', '1.2.23')
> ]
> the parser is satisfied upon finding that all the array elements are
> of type RECORD. It doesn't do anything to make sure they are all of
> the *same* anonymous record type ... and here they are not. The
> second one is just RECORD(UNKNOWN, UNKNOWN, UNKNOWN), which doesn't
> even have a compatible representation with the first one. So at runtime
> we end up trying to disassemble a tuple containing three UNKNOWN fields
> using a tupledesc for the other rowtype.
> I think it wouldn't take too much code to defend against this in
> transformArrayExpr, but I'm a tad worried about whether there are
> similar cases elsewhere. The generic problem is that we suppose that
> different values are compatible if they have the same type OID, but
> for RECORD types that's really not true.
On reflection, I think that the current system design for this is
predicated on the theory that RECORDs really are all the same type, and
the executor had better be prepared to cope with a series of RECORDs
that have different tupdescs, or throw error if it cannot. We can see
that theory at work in record_out() for example. On that theory, the
blame for this crash should be pinned on ExecMakeTableFunctionResult(),
which is assuming that all records returned by the SRF will have the
same typmod. It ought to check that instead of just assuming.
I like this theory mainly because it leads to a back-patchable fix in
just one place. Trying to get the parser to enforce safety at parse
time was turning into a horrendous mess :-(
regards, tom lane