Robert Haas <robertmh...@gmail.com> writes: > Well, having spent a year or more trying to convince you that we need > sql_drop - mostly because of the complexities of passing an array of > arguments to the trigger function - I now think we don't, because the > pg_event_trigger_dropped_objects() bit solves that problem rather > elegantly. It seems to me with just a little bit of hacking we should > be able to make this work by adding that function and changing nothing > else. I might be wrong, of course.
It's not exactly like we don't need to add anything else than just the
function to support the feature, but it's not that much either. Please
see attached.
doc/src/sgml/event-trigger.sgml | 15 +-
doc/src/sgml/func.sgml | 48 ++++++-
src/backend/access/transam/xact.c | 8 +-
src/backend/catalog/dependency.c | 38 +----
src/backend/commands/event_trigger.c | 123 ++++++++++++++++-
src/backend/tcop/utility.c | 28 +++-
src/include/catalog/dependency.h | 31 ++++-
src/include/catalog/pg_proc.h | 4 +-
src/include/commands/event_trigger.h | 21 +++
src/include/utils/builtins.h | 3 +
src/test/regress/expected/event_trigger.out | 67 ++++++++-
src/test/regress/sql/event_trigger.sql | 39 +++++-
12 files changed, 374 insertions(+), 51 deletions(-)
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
dropped_objects.0.patch.gz
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
