Re: Allow a prosupport function to be attached to an aggregate

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrei Lepikhov <lepihov(at)gmail(dot)com>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Subject: Re: Allow a prosupport function to be attached to an aggregate
Date: 2026-08-20 19:47:45
Message-ID: 3954875.1787255265@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrei Lepikhov <lepihov(at)gmail(dot)com> writes:
> Also, I'm not sure why pg_dump/upgrade has not been implemented. So, I
> added an 'unsupported' clause into the docs - let's discuss it later or
> correct me if such a feature can't be supported at all.

Shame on me, I didn't think about that angle.

After reflection I realized that the approach I took in my first patch
is wrong: letting ALTER FUNCTION work on an aggregate is pretty
non-orthogonal, if the only property it can set is SUPPORT. The right
way to do this is to add a SUPPORT option to CREATE AGGREGATE, which
slots nicely into getting pg_dump to handle it. As attached.

One thing I don't quite love about this is that the CREATE AGGREGATE
docs already refer to transfn, finalfn, etc as "support functions",
so that there's a potential for confusion as to what SUPPORT really
means. I considered naming the option something else, but it feels
wrong to not use the same name as in CREATE FUNCTION. Any other
opinions about that?

regards, tom lane

Attachment Content-Type Size
v2-0001-Allow-an-aggregate-s-planner-support-function-to-.patch text/x-diff 14.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2026-08-20 19:56:52 Re: toast table corrupted by vacuum - missing chunk number 0 for toast value
Previous Message Alexander Lakhin 2026-08-20 19:00:00 Test 030_pager.pl might fail due to race on set_winsize