|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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 http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
|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|