Re: sql_drop Event Trigger - Mailing list pgsql-hackers

From Robert Haas
Subject Re: sql_drop Event Trigger
Date
Msg-id CA+Tgmob8dWXQ1v=7LSVE+7EBaWiCKJYddGjGJxq-h-pC7D98KQ@mail.gmail.com
Whole thread Raw
In response to Re: sql_drop Event Trigger  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: sql_drop Event Trigger
List pgsql-hackers
On Sun, Feb 17, 2013 at 4:12 PM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
>>> Well, a list of object OIDs is of exactly zero use once the command
>>> has been carried out.  So I don't think that that represents a useful
>>> or even very testable feature on its own, if there's no provision to
>>> fire user code while the OIDs are still in the catalogs.
>
> That's the reason why I've been proposing that we first add some
> information to the event triggers, then see about the DROP support.

I think the question of the interface to the data and the data to
expose are pretty tightly related.  You can't exactly get one right
and the other one wrong and say, OK, we'll fix it later.

> You might want to realize that the current event triggers implementation
> is not even publishing the object ID now, only the command tag and the
> name of the event.

I know that.  I also know that after I committed this patch in July,
many months went by before we had any further discussion of next
steps.  I'll admit that some of this stuff was on the table for the
November CommitFest, but I also won't accept complete blame for the
fact that we're not further along than we are.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Materialized views WIP patch
Next
From: Andres Freund
Date:
Subject: Re: [RFC] indirect toast tuple support