Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > Hmm, quoth > http://www.postgresql.org/message-id/23345.1358476...@sss.pgh.pa.us : > >> I'd really like to get to a point where we can >> define things as happening like this: >> >> * collect information needed to interpret the DDL command >> (lookup and lock objects, etc) >> * fire "before" event triggers, if any (and if so, recheck info) >> * do the command >> * fire "after" event triggers, if any > > Note that in the snippet I posted above objects have already been looked > up and locked (first phase above).
Ok, I like what you did, but what you did is reinstall the "sql_drop" event and is not complete, as you mention we have some hard problems to solve there. > But I don't think "code structure convenience" is the only reason to do > things this way instead of postponing firing the trigger until the end. > I think complete support for drop event triggers really needs to have > the objects to be dropped still in catalogs, so that they can be looked > up; for instance, user code might want to check the names of the > columns and take particular actions if particular names or particular > types are present. That doesn't seem an easy thing to do if all you get > is pg_dropped_objects(), because how do you know which columns belong to > which tables? Agreed. In terms of Robert's reviewing, though, I think you're talking about another patch entirely, that will get worked on in the 9.4 cycle. And in my terms, doing all that work now is useless anyway because we are not exposing any object specific information that allow the user to do any actual catalog lookup anyway, yet. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
