Re: Typing Records

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Typing Records
Date: 2010-08-24 15:32:48
Message-ID: 29648.1282663968@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"David E. Wheeler" <david(at)kineticode(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-08-24 15:35:35 Re: EXPLAIN doesn't show the actual function expression for FunctionScan
Previous Message Andres Freund 2010-08-24 15:27:45 Re: EXPLAIN doesn't show the actual function expression for FunctionScan