Re: BUG #17387: Working in PG13 but not in PGH14: array_agg(RECORD) - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #17387: Working in PG13 but not in PGH14: array_agg(RECORD)
Date
Msg-id 2808394.1643406921@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #17387: Working in PG13 but not in PGH14: array_agg(RECORD)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #17387: Working in PG13 but not in PGH14: array_agg(RECORD)  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #17387: Working in PG13 but not in PGH14: array_agg(RECORD)
Next
From: Tom Lane
Date:
Subject: Re: BUG #17387: Working in PG13 but not in PGH14: array_agg(RECORD)