Re: sql_drop Event Trigger - Mailing list pgsql-hackers
From | Alvaro Herrera |
---|---|
Subject | Re: sql_drop Event Trigger |
Date | |
Msg-id | 20130305223752.GQ9507@alvh.no-ip.org Whole thread Raw |
In response to | Re: sql_drop Event Trigger (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Responses |
Re: sql_drop Event Trigger
(Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: sql_drop Event Trigger (Robert Haas <robertmhaas@gmail.com>) |
List | pgsql-hackers |
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
pgsql-hackers by date: