Re: sql_drop Event Trigger

Okay, I added a couple of lines to skip reporting dropped temp schemas,
and to skip any objects belonging to any temp schema (not just my own,
note).  Not posting a new version because the change is pretty trivial.

Now, one last thing that comes up is what about objects that don't have
straight names (such as pg_amop, pg_amproc, pg_default_acl etc etc), the
only thing you get is a catalog OID and an object OID ... but they are
pretty useless because by the time you get to the ddl_command_end
trigger, the objects are gone from the catalog.  Maybe we should report
*something* about those.  Say, perhaps the object description ... but if
we want that, it should be untranslated (i.e. not just what
getObjectDescription gives you, because that may be translated, so we
would need to patch it so that it only translates if the caller requests
it)

Another example is reporting of functions: right now you get the
function name .. but if there are overloaded functions there's no way to
know wihch one was dropped.  Example:

alvherre=# create function f(int, int) returns int language sql as $$ select $1 + $2; $$;
CREATE FUNCTION
alvherre=# create function f(int, int, int) returns int language sql as $$ select $1 + $2 + $3; $$;
CREATE FUNCTION
alvherre=# drop function f(int, int);
DROP FUNCTION
alvherre=# select * from dropped_objects ;  type   | schema |  object   | subobj | curr_user | sess_user
----------+--------+-----------+--------+-----------+-----------function | public | f         |        | alvherre  |
alvherre

Maybe we could use the "subobject_name" field (what you see as subobj
above) to store the function signature (perhaps excluding the function
name), for example.  So you'd get object="f" subobject="(int,int)".
Or maybe we should stash the whole function signature as name and leave
subobject NULL.

The reason I'm worrying about this is that it might be important for
some use cases.  For instance, replication cases probably don't care
about that at all.  But if we want to be able to use event triggers for
auditing user activity, we need this info.

Thoughts?

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