Re: Command Triggers - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Command Triggers
Date
Msg-id m2pqfv9bv8.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: Command Triggers  (Andres Freund <andres@anarazel.de>)
Responses Re: Command Triggers  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi,

Andres Freund <andres@anarazel.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


pgsql-hackers by date:

Previous
From: Yeb Havinga
Date:
Subject: Re: [REVIEW] Patch for cursor calling with named parameters
Next
From: Peter Eisentraut
Date:
Subject: Re: Command Triggers