Robert Haas <robertmh...@gmail.com> writes: >> Robert, you specifically opposed to "sql_drop" and I just removed it >> from the patch. What do you think now? Also, should that be a follow-up >> patch to the current one for your reviewing purposes? > > Well, if it has a different firing point than ddl_command_end, then > there could well be some point to having it after all. But I'm far > from convinced that the proposed firing point can be made safe without > a major refactoring. I think this is the sort of things where "design > before code" ought to be the cardinal rule.
Ok se we are in agreement here. I think we should see about getting the dropped_objects.3.patch.gz in (pending review), then continue with that patch series: - publishing some object specific information in TG_* - deciding on a design for generated commands, maybe commit it if it happens to look a lot like what I already have done those past years - adding a function pg_get_normalized_command_string(parsetree) that takes as input internal (Node *) and provide a text as output Note: all that code exists already, in a more or less complete form, and has been around for between 1 and 2 years. I'm *not* trying to push *new* things in the current commit fest, only to make it so that the current patch series deliver a minimum set of features that is usable by itself. Have a look at my slides from FOSDEM where I tried to share my vision here. I don't have a use case for Event Triggers without them publishing object or command specific information, as is currently the case in our tree: http://tapoueh.org/images/confs/Fosdem2013_Event_Triggers.pdf 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