On 11/9/20 5:15 PM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> 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 fix that will work all the way back
>> to 9.2, which is where we start upgrade testing?
> 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. We have provision for adjusting the source
database before we try to upgrade it. Let me know exactly what you have
in mind and I'll try to make it work without having to mangle the
supposedly frozen back branches.
We don't actually run the regression suite regularly for non-live
branches, we just try to upgrade a completely static data dir.
>
>>> 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.
> array_agg goes back to 8.4, and for at least most of that time it's
> been very much more efficient than anything based on array_cat. So I
> think it's past time to push any such laggards into the 21st century.
>
>
fair enough
cheers
andrew