Re: sql_drop Event Trigger

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: sql_drop Event Trigger
Date: 2013-02-06 14:36:38
Message-ID: m27gmlldah.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> variable, it seems like there are a number of ways this can go wrong.

Yeah, I think the current behavior might be surprising.

> I have not tested the actual behavior of the latest patch, but I think
> we want to define things so that the
> pg_event_trigger_dropped_objects() function returns, specifically, the
> list of objects dropped by the command which caused the event trigger
> to fire. In other words, in the above example, the first, recursive
> invocation of B should see the object removed by A's DROP-IF-EXISTS,
> and the second invocation should see the object removed by the
> toplevel command.

I disagree with that. I don't see why the enclosing event trigger
shouldn't be aware of all the objects dropped by the command that just
ran to completion, *including* the effects of any event trigger fired
recursively or not.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2013-02-06 14:38:35 Re: palloc unification
Previous Message Robert Haas 2013-02-06 14:28:29 Re: palloc unification