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

Andrei Lepikhov <lepihov(at)gmail(dot)com> writes:
> 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.

How so? The expectation is that you'd issue CREATE OR REPLACE
AGGREGATE. It is a bit tedious to have to re-specify all the
existing properties, but that's the way previous extensions of
aggregate options have been handled. I don't feel that this one
new feature is a big enough deal to redesign that (especially
not this late in beta).

> What I want to optimise is the built-in functions like
> sum(), avg(), and similar ones, because those are what users
> actually use.

For those, wouldn't we just modify the initial contents of pg_proc?

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

I'm not particularly on board with this goal: I think letting
extensions modify built-in aggregates is fraught with all sorts
of issues. (To name only one, there's no way for multiple
extensions to each attach new behaviors to the same aggregate.)
I'm certainly not going to risk putting in half-considered
support for such a thing at this stage of the release cycle.
There's enough risk in adding what I proposed yesterday.

regards, tom lane