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-29 03:44:04
Message-ID: 2937447.1643427844@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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

Sure enough, transformAExprIn has a related bug: if all the IN
arguments are of the same typcategory, it will try to stuff them
all into an array, whether or not they're actually coercible
to a common type. We should fall back to the x = v1 OR x = v2 ...
interpretation when that's not possible. I failed to come up
with a simple example in which that leads to success; odds are
that there's no suitable = operators either. But it's probably
possible with some weird set of user-defined types. In any
case, the intent of the existing code is clearly that this
should happen.

That bug is ancient, more than 10 years old. Given the lack
of field complaints I'm not terribly worried about back-patching,
but I suppose it can go into v14 along with the regression fix.

regards, tom lane

Attachment Content-Type Size
fix-missing-coercion-checks-2.patch text/x-diff 9.3 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2022-01-29 05:43:08 Re: BUG #17386: btree index corruption after reindex concurrently on write heavy table
Previous Message Peter Geoghegan 2022-01-29 03:00:31 Re: BUG #17386: btree index corruption after reindex concurrently on write heavy table