| From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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-21 15:06:42 |
| Message-ID: | 1f2140fe-e4ae-4a52-9365-d5cbadcf5ae4@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 20/08/2026 22:06, Tom Lane wrote:
> I wrote:
>> 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.
>
> Grumble ... for some reason I was thinking that ProcedureCreate would
> handle checking for superuser when specifying a support function,
> but it doesn't; AggregateCreate must do that. v3 attached contains
> just that one addition.
Thanks. For aggregates that an extension defines itself, this is clearly the
right approach, and the pg_dump part is exactly what v0 was missing.
It does leave out the case I started with, though: attaching a support function
to an existing aggregate. What I want to optimise is the built-in functions like
sum(), avg(), and similar ones, because those are what users actually use. With
only CREATE OR REPLACE AGGREGATE available, an extension would have to restate
the whole definition of pg_catalog.sum(numeric), including sfunc, combinefunc,
and so on, and keep that copy updated with every major release. Even worse,
CREATE OR REPLACE in an extension script should record an extension dependency,
so pg_catalog.sum would become a member of the extension and DROP EXTENSION
would try to drop it.
ALTER AGGREGATE ... SUPPORT avoids both problems, and for this use case it does
not need anything from pg_dump. The statement is part of the extension script,
so CREATE EXTENSION replays it on restore. That is why v0 had both forms. Could
we commit your patch now and add the ALTER form as well, in v20 if it is too
late for v19?
Also, I am not sure I understand the reason for not exporting
interpret_func_support(), as v0 did, instead of repeating the lookup,
return-type, and superuser checks.
> One thing I don't quite love about this is that the CREATE AGGREGATE
> docs already refer to transfn, finalfn, etc as "support functions",
In v0, I just added a paragraph to the create_aggregate.sgml:
"Note that this is unrelated to the aggregate's transition, final and other
helper functions described above, which implement the aggregate itself; a
planner support function instead advises the planner about calls to the aggregate."
I think this should be enough.
--
regards, Andrei Lepikhov,
pgEdge
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2026-08-21 15:20:20 | Re: hashjoins vs. Bloom filters (yet again) |
| Previous Message | Tomas Vondra | 2026-08-21 14:35:58 | Re: Apply extended statistics to join clause during parameterized path costing |