CREATE OR REPLACE 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:t40298psql -h localhost -U postgresBuilt from patchset v4 (message #4), July 28, 2026 at 04:30 AM.
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 t40298_4 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 t40298_4 && git checkout t40298_4Patchset v4 (message #4) is on t40298_4
So some PostGIS people were griping (on irc) about how the lack of
CREATE OR REPLACE AGGREGATE made their life difficult for updates. It
struck me that aggregates have acquired a relatively large number of new
attributes in recent years, almost all of which are applicable at
execution time rather than in parse analysis, so having a CREATE OR
REPLACE option seems like a no-brainer.
I took a bash at actually writing it and didn't see any obvious problems
(I'll post the patch in a bit). Is there some reason (other than
shortage of round tuits) why this might not be a good idea, or why it
hasn't been done before?
--
Andrew (irc:RhodiumToad)
On Sun, Mar 17, 2019 at 07:35:16AM +0000, Andrew Gierth wrote:
I took a bash at actually writing it and didn't see any obvious problems
(I'll post the patch in a bit). Is there some reason (other than
shortage of round tuits) why this might not be a good idea, or why it
hasn't been done before?
Indeed. There is not much on the matter in pgsql-hackers as far as I
can see, except that but the thread is short:
/messages/by-id/CAGYyBgj3u_4mfTNPMnpOM2NPtWQVPU4WRsYz=RLCF59g-kGVmQ@mail.gmail.com
--
Michael
Michael Paquier <michael@paquier.xyz> writes:
On Sun, Mar 17, 2019 at 07:35:16AM +0000, Andrew Gierth wrote:
I took a bash at actually writing it and didn't see any obvious problems
(I'll post the patch in a bit). Is there some reason (other than
shortage of round tuits) why this might not be a good idea, or why it
hasn't been done before?
Indeed.
Yeah, it seems like mostly a lack-of-round-tuits problem.
Updating the aggregate's dependencies correctly might be a bit tricky, but
it can't be any worse than the corresponding problem for functions...
regards, tom lane
"Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> Yeah, it seems like mostly a lack-of-round-tuits problem.
Tom> Updating the aggregate's dependencies correctly might be a bit
Tom> tricky, but it can't be any worse than the corresponding problem
Tom> for functions...
I was worried about that myself but looking at it, unless I overlooked
something, it's not hard to deal with. The main thing is that all the
dependencies attach to the pg_proc entry, not the pg_aggregate row
(which has no oid anyway), and ProcedureCreate when replacing that will
delete all of the old dependency entries. So all that AggregateCreate
ends up having to do is to create the same set of dependency entries
that it would have created anyway.
Here's my initial draft patch (includes docs but not tests yet) - I have
more testing to do on it, particularly to check the dependencies are
right, but so far it seems to work.
--
Andrew (irc:RhodiumToad)