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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: james.inform@pharmapp.de, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2022-01-29T03:44:04Z
Lists: pgsql-bugs

Attachments

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

Commits

  1. Fix failure to validate the result of select_common_type().

  2. Declare assorted array functions using anycompatible not anyelement.