pgsql: Declare assorted array functions using anycompatible not anyelem

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 where there's a pretty obvious
gain in usability from doing so.

Ideally we'd also modify other functions taking multiple old-style
polymorphic arguments. But most of the remainder are tied into one
or more operator classes, making any such change a much larger can of
worms than I desire to open right now.

Discussion: https://postgr.es/m/[email protected]

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/9e38c2bb5093ceb0c04d6315ccd8975bd17add66

Modified Files
--------------
doc/src/sgml/func.sgml | 50 ++++++++++++++++--------------
doc/src/sgml/xaggr.sgml | 4 +--
src/include/catalog/catversion.h | 2 +-
src/include/catalog/pg_operator.dat | 13 ++++----
src/include/catalog/pg_proc.dat | 40 +++++++++++++++---------
src/test/regress/expected/arrays.out | 12 +++++++
src/test/regress/expected/polymorphism.out | 10 +++---
src/test/regress/sql/arrays.sql | 2 ++
src/test/regress/sql/polymorphism.sql | 10 +++---
9 files changed, 86 insertions(+), 57 deletions(-)

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 of commit
> 5c292e6b9 to hit some other places where there's a pretty obvious
> gain in usability from doing so.
>
> Ideally we'd also modify other functions taking multiple old-style
> polymorphic arguments. But most of the remainder are tied into one
> or more operator classes, making any such change a much larger can of
> worms than I desire to open right now.
>
> Discussion: https://postgr.es/m/[email protected]
>

This patch broke cross-version pg_upgrade testing. I have cured crake
for the moment by having it execute this in the source database:

    drop aggregate if exists public.array_cat_accum(anyarray);
    drop aggregate if exists public.first_el_agg_any(anyelement);

But I wonder if we really want to make it impossible to upgrade
databases with aggregates that contain these functions?

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)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?

> 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.

> 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.

regards, tom lane

[1] https://www.postgresql.org/message-id/1915573.1604879242%40sss.pgh.pa.us

On 11/9/20 4:29 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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

Andrew Dunstan <andrew(at)dunslane(dot)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.

>> 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.

regards, tom lane

On 11/9/20 5:15 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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

Andrew Dunstan <andrew(at)dunslane(dot)net> 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. 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.

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 other
user-defined aggregates in the regression database.

regards, tom lane

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 other
> user-defined aggregates in the regression database.

You also need to modify first_el_agg_any.

Here's what I have working on crake::

        if ($oversion le 'REL9_4_STABLE')
        {
            # this is to be fixed in 9.5 and later
            $prstmt = join(';',
                           'drop aggregate if exists
public.array_cat_accum(anyarray)',
                           'CREATE AGGREGATE array_larger_accum
(anyarray) ' .
                           ' ( ' .
                           '   sfunc = array_larger, ' .
                           '   stype = anyarray, ' .
                           '   initcond = $${}$$ ' .
                           '  ) ' );
            system( "$other_branch/inst/bin/psql -X -e "
                      . " -c '" . $prstmt . "' "
                      . "regression "
                      . ">> '$upgrade_loc/$oversion-copy.log' 2>&1");
            return if $?;
        }
        # drop this branch when upstream is renovated
        else
        {
            $prstmt = join(';',
                          'drop aggregate if exists
public.array_cat_accum(anyarray)',
                          'drop aggregate if exists
public.first_el_agg_any(anyelement)');
            system( "$other_branch/inst/bin/psql -X -e "
                      . " -c '$prstmt' "
                      . "regression "
                      . ">> '$upgrade_loc/$oversion-copy.log' 2>&1");
            return if $?;
        }

When you fix the live branches I'll delete the "else" branch and push
the change to the git repo.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> 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 that is to add a
SQL-language wrapper to reproduce the old signature for array_append.
As attached. (I'm keeping this separate from the other patch, since
this doesn't go back as far.)

> Here's what I have working on crake::

OK.

regards, tom lane

On 11/10/20 3:31 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> 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 that is to add a
> SQL-language wrapper to reproduce the old signature for array_append.
> As attached. (I'm keeping this separate from the other patch, since
> this doesn't go back as far.)
>
>

Seems reasonable.

cheers

andrew