"David E. Wheeler" <david@kineticode.com> writes:
> On Aug 24, 2010, at 7:05 AM, Tom Lane wrote:
>> I get a core dump on that one ... looking ...
> Well I'm glad I reported it, then.
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.
regards, tom lane
