sql_drop Event Trigger

Hi,

I took the liberty to create a new thread for $subject, because the main
comments I've been receiving about Event Triggers at this point is how
difficult it is to try and follow our discussions about them.

In order for everybody interested to be able to easily get the important
bits of information from this patch series and review, I'm now going to
work on a wiki page that I will then update when needed.

The important messages you will need to refer to for more context in
this thread are:

  http://www.postgresql.org/message-id/m21udesaz3.fsf@2ndQuadrant.fr
  http://www.postgresql.org/message-id/CA+TgmoZz6MXQ5zX6dopc_xaHVkdwhEhgDFJeAWsRNs+N7e_ueA@mail.gmail.com

So please find attached to this email an implementation of the sql_drop
event trigger, that refrains on exposing any new information to the
users.

    COLUMNS=72 git diff --stat master..
     doc/src/sgml/event-trigger.sgml             |   98 +++++++-
     doc/src/sgml/func.sgml                      |   47 +++-
     src/backend/catalog/dependency.c            |    7 +
     src/backend/commands/event_trigger.c        |  233 ++++++++++++++++++-
     src/backend/tcop/utility.c                  |   23 +-
     src/backend/utils/cache/evtcache.c          |    2 +
     src/include/catalog/pg_proc.h               |    4 +-
     src/include/commands/event_trigger.h        |   18 ++
     src/include/utils/builtins.h                |    3 +
     src/include/utils/evtcache.h                |    3 +-
     src/test/regress/expected/event_trigger.out |   53 +++++
     src/test/regress/sql/event_trigger.sql      |   37 +++
     12 files changed, 519 insertions(+), 9 deletions(-)

The implementation follows Robert ideas in that we accumulate
information about objects we are dropping then provide it to the Event
Trigger User Function. The way to provide it is using a Set Returning
Function called pg_dropped_objects() and that is only available when
running a "sql_drop" event trigger.

This functions returns a set of classid, objid, objsubid (as in
pg_depend), but you have to remember that you can't use them for catalog
lookups as the objects are already dropped: we can't both decide not to
add any concurrency hazards, no new lookups and locking nor extra work
in dependency.c *and* get at the OID of the DROP CASCADEd objects before
the drop happens, as far as I understand it.

I hope to complement the information available in a follow-up patch,
where I intend to provide object name, id, kind, schema name and
operation name in all supported operations.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support