Re: Command Triggers

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Subject: Re: Command Triggers
Date: 2011-12-11 18:55:39
Message-ID: m2pqfv9bv8.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Andres Freund <andres(at)anarazel(dot)de> writes:
> Hm. I just noticed a relatively big hole in the patch: The handling of
> deletion of dependent objects currently is nonexistant because they don't go
> through ProcessUtility...

That's the reason why we're talking about “command triggers” rather than
“DDL triggers”. We don't intend to fire the triggers at each DDL
operation happening on the server, but for each command.

This restriction still allows us to provide a very useful feature when
checked against the main use cases we target here. Those are auditing,
and replication (the replay will also CASCADEs), and a generic enough
SUDO facility (because the trigger function can well be SECURITY
DEFINER).

We could also add a 'cascading bool' parameter to the trigger function
API and have that always false in 9.2, then choose what to fill the
other parameters with in a later release. The obvious risk would be to
decide that we need another API, then we didn't make a good move after
all.

My current feeling and vote is thus to leave that alone and document the
restriction.

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 Peter Eisentraut 2011-12-11 19:09:36 Re: Command Triggers
Previous Message Yeb Havinga 2011-12-11 15:26:33 Re: [REVIEW] Patch for cursor calling with named parameters