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