Re: CREATE OR REPLACE AGGREGATE?

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: CREATE OR REPLACE AGGREGATE?
Date: 2019-03-17 20:38:53
Message-ID: 87va0h453x.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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)

Attachment Content-Type Size
cor_agg.patch text/x-patch 12.6 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-03-17 21:08:12 Re: Performance issue in foreign-key-aware join estimation
Previous Message Tom Lane 2019-03-17 19:41:43 Re: Unduly short fuse in RequestCheckpoint