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 21:55:21
Message-ID: 2808394.1643406921@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

I wrote:
> ... which was non-ambiguous because in this usage, anyelement
> wouldn't match an array type. I wonder why that's not
> happening with the anycompatible family?

Poking further, this case still works:

regression=# select array[1] || array[2];
?column?
----------
{1,2}
(1 row)

so we didn't break it completely (I rather imagine we have
regression tests that would have noticed that). Also,
you can still concatenate arrays of known composite types:

regression=# select array_agg(t) || array_agg(t) from int8_tbl t;

?column?


--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
-----------------------------------------
{"(123,456)","(123,4567890123456789)","(4567890123456789,123)","(45678901234567
89,4567890123456789)","(4567890123456789,-4567890123456789)","(123,456)","(123,4
567890123456789)","(4567890123456789,123)","(4567890123456789,4567890123456789)"
,"(4567890123456789,-4567890123456789)"}
(1 row)

So it seems like this is specific to type record[] somehow.
Odd.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2022-01-28 23:48:00 Re: BUG #17387: Working in PG13 but not in PGH14: array_agg(RECORD)
Previous Message Tom Lane 2022-01-28 21:43:18 Re: BUG #17387: Working in PG13 but not in PGH14: array_agg(RECORD)