Re: sql_drop Event Triggerg

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: sql_drop Event Triggerg
Date: 2013-03-27 05:06:33
Message-ID: 20130327050633.GE3881@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera escribió:

> However, I think previous discussions have conflated many different
> things, and we've been slowly fixing them one by one; so perhaps at this
> point it does make sense to have a new object-drop event. Let's discuss
> it -- we would define it as taking place just before ddl_command_end,
> and firing any time a command (with matching tag?) has called
> performDeletion or performMultipleDeletions. Does that sound okay?

Here's another version of this patch. I hope this is really final now
... but then, that's what I thought of the previous two versions, too.

I have re-instated event sql_drop, which takes place just before
ddl_command_end, and is called a single time per command (not once per
object dropped, as the old definition would have had it). Within a
function running in that event, you can call
pg_event_trigger_dropped_object(); that will give you a list of all
objects that have been dropped. Since the deletion command has already
been run, the objects are not in catalogs anymore. There are no magic
TG_* variables about objects deleted. I'm a bit unhappy about having to
add calls to EventTriggerSQLDrop() just before each call to
EventTriggerDDLCommandEnd(), but I didn't see any way to make this less
duplicative.

Docs and regression tests have been minimally fixed.

The new event is called sql_drop, note.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
dropped_objects.10.patch text/x-diff 73.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-03-27 05:27:07 Re: GSoC project : K-medoids clustering in Madlib
Previous Message Atri Sharma 2013-03-27 04:27:21 Re: GSoC project : K-medoids clustering in Madlib