Re: sql_drop Event Triggerg

Alvaro Herrera escribió:

> > I am inclined to think that putting this logic in ProcessUtility isn't
> > scalable, even for CREATE, and even moreso for ALTER, unless we can
> > put it around everything in that function, rather than each command
> > individually. Suppose for example that on entry to that function we
> > simply did this:
> >
> > if (isCompleteQuery)
> > ++CompleteQueryNestingLevel;
> >
> > ...and at exit, we did the reverse. This could work a bit like the
> > GUC nesting level.
>
> Hmm, this seems an interesting idea to explore.

Okay, here's a patch implementing the spirit of this idea. We don't
keep track of a nesting level per se; I tried that approach and it
seemed a dead end. Instead I created a pair of macros that are pretty
much the same as UTILITY_BEGIN_DROP, except that they enclose the whole
of ProcessUtility instead of individual commands. These macros set up a
context for event_trigger.c to record affected actions/objects.
Currently this only keeps track of dropped objects (which is what this
particular patch is all about), but it appears reasonably simple to
extend to objects created, and subcommands of ALTER.

I have also modified the return type of
pg_event_trigger_dropped_objects, so that instead of object name it
returns object identity (as well as object type and schema name). For
example, for functions the identity is the signature; for tables, it's
the name. Each object type has its own format, modelled after the
COMMENT syntax (some object types don't have COMMENT support, so I had
to come up with some. This might need further discussion to arrive at
the best possible rendering for each object class). I had to add a
nearly-duplicate of getObjectDescription for this, which needs a bit
more work yet so that it doesn't schema-qualify the object names even
when not in path (most objects are not qualified, but I think operators
and types still are.)

(There's no SQL-callable function to get the object identity, such as
what we have as pg_describe_object. Not sure how important this is.)

Also, we need to ensure that unsupported object types such as
pg_default_acl rows are not reported. I have not tested this yet.
Supposedly this is part of a future patch that will encompass all DCL
commands (grant, revoke, create/drop roles, etc).

This patch also adds event trigger support for DROP OWNED (a two-line
change).

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