Re: pgsql: Declare assorted array functions using anycompatible not anyelem

2020-11-11 Thread Andrew Dunstan
On 11/10/20 3:31 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 11/9/20 5:41 PM, Tom Lane wrote: >>> What I have in mind to apply to 9.5 through 13 is per attached. >> You also need to modify first_el_agg_any. > ... doh. That one is a little messier because there's no equally useful > subst

Re: pgsql: Declare assorted array functions using anycompatible not anyelem

2020-11-10 Thread Tom Lane
Andrew Dunstan writes: > On 11/9/20 5:41 PM, Tom Lane wrote: >> What I have in mind to apply to 9.5 through 13 is per attached. > You also need to modify first_el_agg_any. ... doh. That one is a little messier because there's no equally useful substitute function. What I'm inclined to do for t

Re: pgsql: Declare assorted array functions using anycompatible not anyelem

2020-11-10 Thread Andrew Dunstan
On 11/9/20 5:41 PM, Tom Lane wrote: > > What I have in mind to apply to 9.5 through 13 is per attached. > You could either redefine the aggregate similarly in 9.2-9.4, > or just drop it. I doubt the latter leads to any interesting > loss of coverage for xversion upgrade, as there's plenty of oth

Re: pgsql: Declare assorted array functions using anycompatible not anyelem

2020-11-09 Thread Tom Lane
Andrew Dunstan writes: > On 11/9/20 5:15 PM, Tom Lane wrote: >> Hm. To fix it this way, we'd have to push the test-script change >> into the pre-9.5 branches. There's no technical reason we can't do >> that, I don't think, though it's a bit outside our normal practices. > I doubt it's necessary

Re: pgsql: Declare assorted array functions using anycompatible not anyelem

2020-11-09 Thread Andrew Dunstan
On 11/9/20 5:15 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 11/9/20 4:29 PM, Tom Lane wrote: >>> 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, thou

Re: pgsql: Declare assorted array functions using anycompatible not anyelem

2020-11-09 Thread Tom Lane
Andrew Dunstan writes: > On 11/9/20 4:29 PM, Tom Lane wrote: >> 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

Re: pgsql: Declare assorted array functions using anycompatible not anyelem

2020-11-09 Thread Andrew Dunstan
On 11/9/20 4:29 PM, Tom Lane wrote: > Andrew Dunstan 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? Ye

Re: pgsql: Declare assorted array functions using anycompatible not anyelem

2020-11-09 Thread Tom Lane
Andrew Dunstan 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? > I have cured crake > for the moment by having

Re: pgsql: Declare assorted array functions using anycompatible not anyelem

2020-11-09 Thread Andrew Dunstan
On 11/4/20 4:10 PM, Tom Lane wrote: > Declare assorted array functions using anycompatible not anyelement. > > Convert array_append, array_prepend, array_cat, array_position, > array_positions, array_remove, array_replace, and width_bucket > to use anycompatiblearray. This is a simple extension

pgsql: Declare assorted array functions using anycompatible not anyelem

2020-11-04 Thread Tom Lane
Declare assorted array functions using anycompatible not anyelement. Convert array_append, array_prepend, array_cat, array_position, array_positions, array_remove, array_replace, and width_bucket to use anycompatiblearray. This is a simple extension of commit 5c292e6b9 to hit some other places wh