Allow a prosupport function to be attached to an aggregate
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253436psql -h localhost -U postgresThis image is from patchset v4 (message #4) - the current patchset v5 (message #5) has not produced an image.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253436_5 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253436_5 && git checkout t253436_5Patchset v5 (message #5) is on t253436_5
Hi,
Commit 42473b3b31 added SupportRequestSimplifyAggref, which the planner issues
for any Aggref whose function names a support function. Nice, but extensions
cannot reach it, because there is no way to attach a support function to an
aggregate:
ALTER FUNCTION pg_catalog.sum(numeric) SUPPORT numeric_support;
ERROR: "pg_catalog.sum" is an aggregate function
CREATE/ALTER aggregate doesn't support this feature at all. This does not look
like a decision about support functions. AlterFunction() rejects an aggregate
for every property it can change, not just for SUPPORT, and the other properties
it covers are ones AggregateCreate() fixes for aggregates anyway. prosupport is
different: nothing else in the catalog determines it, so refusing to set it
leaves the capability simply unreachable rather than merely inconvenient.
Updating pg_proc directly is not an answer. It records no pg_depend entry, so
the support function can then be dropped and leave a dangling OID behind.
My interest is extension-defined optimizations of numeric aggregates [1]https://github.com/danolivo/pg_numeric_agg_support or even
more extravagant dumb transformations, like the following (doable for specific
conditions):
SUM(x ORDER BY x) → SUM(x)
SUM(x) FILTER (WHERE true) → SUM(x)
SUM(N) -> N * COUNT(*)
Please find attached a patch adding SUPPORT to CREATE AGGREGATE's option
list and an ALTER AGGREGATE ... SUPPORT form. Both require superuser,
as the equivalent function clauses do, and record a normal dependency.
[1]: https://github.com/danolivo/pg_numeric_agg_support
--
regards, Andrei Lepikhov,
pgEdge
On Mon, 17 Aug 2026 at 18:13, Andrei Lepikhov <lepihov@gmail.com> wrote:
Commit 42473b3b31 added SupportRequestSimplifyAggref, which the planner issues
for any Aggref whose function names a support function. Nice, but extensions
cannot reach it, because there is no way to attach a support function to an
aggregate:ALTER FUNCTION pg_catalog.sum(numeric) SUPPORT numeric_support;
ERROR: "pg_catalog.sum" is an aggregate function
I failed to realise that there was no way to set that for user-defined
aggregates. Not good. While I do agree that lack of extensibility is
not aligned with the spirit of the project, my current thoughts are
that now is a bit late to add this to v19.
Is delaying this until v20 fine for you?
Or does anyone else feel this is a must-fix for v19?
David
On 18/08/2026 06:56, David Rowley wrote:
On Mon, 17 Aug 2026 at 18:13, Andrei Lepikhov <lepihov@gmail.com> wrote:
Commit 42473b3b31 added SupportRequestSimplifyAggref, which the planner issues
for any Aggref whose function names a support function. Nice, but extensions
cannot reach it, because there is no way to attach a support function to an
aggregate:ALTER FUNCTION pg_catalog.sum(numeric) SUPPORT numeric_support;
ERROR: "pg_catalog.sum" is an aggregate functionI failed to realise that there was no way to set that for user-defined
aggregates. Not good. While I do agree that lack of extensibility is
not aligned with the spirit of the project, my current thoughts are
that now is a bit late to add this to v19.Is delaying this until v20 fine for you?
Yes, I can do it manually in pg_catalog for now - rewriting prosupport and
setting the dependency in the pg_depend. There’s no rush - it’s just about
keeping things tidy.
--
regards, Andrei Lepikhov,
pgEdge
On 18/08/2026 08:31, Andrei Lepikhov wrote:
On 18/08/2026 06:56, David Rowley wrote:
Is delaying this until v20 fine for you?
Yes, I can do it manually in pg_catalog for now - rewriting prosupport and
setting the dependency in the pg_depend. There’s no rush - it’s just about
keeping things tidy.
However, I noticed that it is not documented yet.
There are also three other prosupport requests that are not documented. A quick
search showed that documentation usually depends on the author, so it makes
sense to add it now.
Since each was introduced at a different time and serves a different purpose, I
suggest we start by documenting SupportRequestSimplifyAggref, as I am more
familiar with it - see the patch in attachment.
--
regards, Andrei Lepikhov,
pgEdge
David Rowley <dgrowleyml@gmail.com> writes:
I failed to realise that there was no way to set that for user-defined
aggregates. Not good. While I do agree that lack of extensibility is
not aligned with the spirit of the project, my current thoughts are
that now is a bit late to add this to v19.
Is delaying this until v20 fine for you?
Or does anyone else feel this is a must-fix for v19?
That seems quite sad. The entire point of the support-function
mechanism is to allow extensibility, so if an extension cannot use
a support hook we have totally failed at implementing that hook.
(As you yourself remarked in a different context, it's unlikely
we would have implemented SupportRequestSimplifyAggref if the only
possible use-case was COUNT(any).)
So I think it's a must-fix. To put my money where my mouth is,
here's a draft patch. (I could not resist the temptation to
improve compute_common_attribute's existing error message,
which pretty well sucks: it's useless in a context that's not
showing you an accurate error pointer.)
regards, tom lane