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
- fix-missing-coercion-checks-2.patch (text/x-diff) patch
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
-
Fix failure to validate the result of select_common_type().
- c025067f6d3f 14.2 landed
- 8e2e0f75869e 15.0 landed
- 5ad70564f46a 13.6 landed
-
Declare assorted array functions using anycompatible not anyelement.
- 9e38c2bb5093 14.0 cited