Re: sql_drop Event Trigger

Robert Haas <robertmhaas(at)gmail(dot)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