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
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 |