Re: BUG #17387: Working in PG13 but not in PGH14: array_agg(RECORD)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: james(dot)inform(at)pharmapp(dot)de, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #17387: Working in PG13 but not in PGH14: array_agg(RECORD)
Date: 2022-01-28 23:48:00
Message-ID: 2856894.1643413680@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

I wrote:
> So it seems like this is specific to type record[] somehow.

Ah, no, I found it: the callers of select_common_type_from_oids
assume that its result is guaranteed valid, which is not so.
We need to explicitly check can_coerce_type. This oversight
allows check_generic_type_consistency to succeed when it should
not, which in turn allows us to decide that record and record[]
are OK as matches to all three of those operators.

This apparently escaped notice before because we've only tested
cases in which incompatible arguments were of different typcategory.
record and record[] are both of category 'P', which might be a
dumb idea. But this would be a bug anyway.

We need something like the attached, but I'm going to nose
around for other oversights.

regards, tom lane

Attachment Content-Type Size
fix-missing-coercion-check.patch text/x-diff 3.4 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Noah Misch 2022-01-29 02:34:18 Re: BUG #17386: btree index corruption after reindex concurrently on write heavy table
Previous Message Tom Lane 2022-01-28 21:55:21 Re: BUG #17387: Working in PG13 but not in PGH14: array_agg(RECORD)