"David E. Wheeler" <da...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers