Re: BUG #17387: Working in PG13 but not in PGH14: array_agg(RECORD)
| От | Tom Lane |
|---|---|
| Тема | Re: BUG #17387: Working in PG13 but not in PGH14: array_agg(RECORD) |
| Дата | |
| Msg-id | 2808394.1643406921@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: BUG #17387: Working in PG13 but not in PGH14: array_agg(RECORD) (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: BUG #17387: Working in PG13 but not in PGH14: array_agg(RECORD)
|
| Список | 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 по дате отправления: