Re: pgsql: Declare assorted array functions using anycompatible not anyelem
От | Andrew Dunstan |
---|---|
Тема | Re: pgsql: Declare assorted array functions using anycompatible not anyelem |
Дата | |
Msg-id | b300679b-6410-9124-271c-73893a2c3a1f@dunslane.net обсуждение исходный текст |
Ответ на | Re: pgsql: Declare assorted array functions using anycompatible not anyelem (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Declare assorted array functions using anycompatible not anyelem
|
Список | pgsql-committers |
On 11/9/20 4:29 PM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> On 11/4/20 4:10 PM, Tom Lane wrote: >>> Declare assorted array functions using anycompatible not anyelement. >> This patch broke cross-version pg_upgrade testing. > Uh, yeah ... didn't you get my two prior messages about that? Yes, I did, although by the time you sent them out I'd already modified crake. > >> I have cured crake >> for the moment by having it execute this in the source database: > I think probably the right fix is just to change that test case to > use a different implementation function, per [1]. I'm holding off > pushing the fix till after this week's wraps, though. I'd be ok with that. Can we devise a fix that will work all the way back to 9.2, which is where we start upgrade testing? > >> But I wonder if we really want to make it impossible to upgrade >> databases with aggregates that contain these functions? > If I thought that user-defined aggregates relying on array_cat were > really a thing (and not just a test case), I'd be more concerned about > this. But it's hard to see why users shouldn't use array_agg() instead > of rolling their own. > > Possibly something that's been migrated from before we had array_agg. cheers andrew
В списке pgsql-committers по дате отправления: