Re: sql_drop Event Trigger

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: sql_drop Event Trigger
Date: 2013-02-01 20:07:31
Message-ID: CA+TgmobDGjURjnzoXP=GPkBy0Z+utT6omEfnEaPN-ajTa4MMfg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 30, 2013 at 12:59 PM, Dimitri Fontaine
<dimitri(at)2ndquadrant(dot)fr> wrote:
> Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
>> So please find attached to this email an implementation of the sql_drop
>> event trigger, that refrains on exposing any new information to the
>> users.
>
> Already a v1 of that patch, per comments from Álvaro I reuse the
> ObjectAddresses facility rather than building my own List of object
> addresses.
>
> Note that with that in place it's now easy to also add support for the
> DROP OWNED BY command, but that's left for a future patch as I expect
> some amount of discussion to go about it.
>
> Also, I removed the code that was doing de-deduplication of the object
> addresses we collect, now trusting performMultipleDeletions() not to
> screw us up. There's a use case that needs particular attention here,
> though:
>
> DROP TABLE foo, foo;
>
> I'm not sure we want to deduplicate foo in the pg_dropped_objects()
> output in that case, so I've not done so in this version of the patch.
> Also, Álvaro is concerned that the cost of deduplicating might be higher
> than what we want to take here.

Taking a first look at this, I think the idea of pg_dropped_objects()
is really pretty clever. I like it. I assure we will end up with
several functions of this type eventually, so it might be good to
adopt some kind of distinguishing naming convention for this type of
function. pg_event_trigger_context_dropped_objects() seems far too
verbose, but that's the idea.

With this approach, there's no real need to introduce a new event
type. We could just make ddl_command_end triggers able to use this,
and we're done. The point of sql_drop was that it would have been
called once *per dropped object*, not once per command. But,
actually, thinking about this, for something like Slony, exposing
pg_dropped_objects() to ddl_command_end triggers should be just as
good, and maybe a whole lot better, than what I was proposing.

Does it work for you to rip out sql_drop and just make
pg_dropped_objects() - perhaps renamed - available in ddl_command_end?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2013-02-01 20:08:58 cannot move relocatable extension out of pg_catalog schema
Previous Message Robert Haas 2013-02-01 19:46:52 Re: Re: [COMMITTERS] pgsql: Tolerate timeline switches while "pg_basebackup -X fetch" is run