Further documentation tweaks for event triggers.

Per discussion between Dimitri Fontaine, myself, and others.

diff --git a/doc/src/sgml/event-trigger.sgml b/doc/src/sgml/event-trigger.sgml
index 48703713d770271a4619c48b0541a7ed0efb1b6e..71241c822450e5199fb2e3a730925a7ef9aa57b0 100644 (file)
--- a/doc/src/sgml/event-trigger.sgml
+++ b/doc/src/sgml/event-trigger.sgml
@@ -41,14 +41,20 @@
      mechanism does not support these object types.
      ddl_command_start also occurs just before the execution of a
      SELECT INTO command, since this is equivalent to
-     CREATE TABLE AS.
+     CREATE TABLE AS.  The ddl_command_end
+     event occurs just after the execution of this same set of commands.
    
 
    
-    The ddl_command_end event occurs just before returning
-    control from the execution of a CREATE, ALTER,
-    or DROP command.  It shares the same exceptions as
-    the ddl_command_start event.
+     Event triggers (like other functions) cannot be executed in an aborted
+     transaction.  Thus, if a DDL command fails with an error, any associated
+     ddl_command_end triggers will not be executed.  Conversely,
+     if a ddl_command_start trigger fails with an error, no
+     further event triggers will fire, and no attempt will be made to execute
+     the command itself.  Similarly, if a ddl_command_end trigger
+     fails with an error, the effects of the DDL statement will be rolled
+     back, just as they would be in any other case where the containing
+     transaction aborts.