Re: sql_drop Event Trigger

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: sql_drop Event Trigger
Date: 2013-02-21 03:48:14
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Here's an implementation of what we discussed: the event is now DDL_DROP
and is called inside performDeletion and performMultipleDeletions; it
receives the list of objects via pg_dropped_objects (though it now has a
more verbose name), and the objects are still catalogued when the
trigger is called. This event does *not* receive the parsetree (as
opposed to ddl_command_start/end); also, there's no tag filtering
support, so if you install a function in that event, it will run every
time a DROP of any kind occurs.

I have added some protections so that these do not fire on undesirable
events (such as dropping an event trigger); also event triggers and
other object types are filtered out of pg_dropped_objects, in case
something like DROP OWNED happens. (So for instance you could get an
empty pg_dropped_objects if you did DROP OWNED and the mentioned user
only owns an event trigger). Maybe this needs to be reconsidered.

There's also code to re-obtain the list of objects to drop after the
event trigger functions have run; the second list is compared to the
first one, and if they differ, an error is raised.

It's rather annoying that performMultipleDeletions and performDeletion
contain almost exactly the same code. I think maybe it's time to morph
the latter into a thin layer on top of the former.

(small remaiing issue: docs need updated).

Álvaro Herrera
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
ddl-drop-3.patch text/x-diff 59.5 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2013-02-21 03:54:40 Re: Re: PostgreSql - access modified rows in prepare transaction command
Previous Message Michael Paquier 2013-02-21 02:55:54 Re: Support for REINDEX CONCURRENTLY