CREATE OR REPLACE AGGREGATE?
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)