Fix #91 - Changed G-7730 to more generic and added G-7740 for specific PK case not supported by PLSQL cop

Author: kibeha

docs/4-language-usage/7-stored-objects/7-triggers/g-7730.md

@@ -1,11 +1,13 @@
-# G-7730: Avoid multiple DML events per trigger if primary key is assigned in trigger.
+# G-7730: Avoid multiple DML events per trigger.
 
-!!! warning "Major"
-    Efficiency, Reliability
+!!! tip "Minor"
+    Maintainability, Testability
 
 ## Reason
 
-If a trigger makes assignment to the primary key anywhere in the trigger code, that causes the session firing the trigger to take a lock on any child tables with a foreign key to this primary key. Even if the assignment is in for example an `if inserting` block and the trigger is fired by an `update` statement, such locks still happen unnecessarily. The issue is avoided by having one trigger for the insert containing the primary key assignment, and another trigger for the update. Or even better by handling the insert assignment as ´default on null´ clauses, so that only an `on update` trigger is needed.
+Rather than a single trigger handling multiple DML events with separated blocks of `if inserting`, `if updating` and `if deleting`, modularity by individual triggers per DML event helps maintaining and testing the code. If most of the code is common for either DML event (only small pieces of code are individual) consider an exception to the rule and allow `if inserting`, `if updating` and `if deleting` blocks, or alternatively gather the common code in a procedure and let individual triggers handle the individual pieces of code plus call the procedure with the common code.
+
+If the trigger makes assignment to a primary key and there are child tables with a foreign key referring to this primary key, the database can make undesirable table locks. If such is the case, you should always use individual triggers. See [G-7740](../../../../4-language-usage/7-stored-objects/7-triggers/g-7740) for details.
 
 ## Example (bad)
 
@@ -15,8 +17,7 @@ before insert or update
 on departments for each row
 begin
    if inserting then
-      :new.department_id := department_seq.nextval;
-      :new.created_date  := sysdate;
+      :new.created_date := sysdate;
    end if;
    if updating then
       :new.changed_date := sysdate;
@@ -25,15 +26,14 @@ end;
 /
 ```
 
-## Example (better)
+## Example (good)
 
 ``` sql
 create or replace trigger dept_br_i
 before insert
 on departments for each row
 begin
-   :new.department_id := department_seq.nextval;
-   :new.created_date  := sysdate;
+   :new.created_date := sysdate;
 end;
 /
 
@@ -45,18 +45,3 @@ begin
 end;
 /
 ```
-
-## Example (good)
-
-``` sql
-alter table department modify department_id default on null department_seq.nextval;
-alter table department modify created_date  default on null sysdate;
-
-create or replace trigger dept_br_u
-before update
-on departments for each row
-begin
-   :new.changed_date := sysdate;
-end;
-/
-```

docs/4-language-usage/7-stored-objects/7-triggers/g-7740.md

@@ -0,0 +1,65 @@
+# G-7740: Never handle multiple DML events per trigger if primary key is assigned in trigger.
+
+!!! warning "Major"
+    Efficiency, Reliability
+
+!!! missing "Unsupported in PL/SQL Cop Validators"
+    We cannot identify what the primary key column(s) are to check if assignment to a primary key is taking place in the trigger.
+
+## Reason
+
+If a trigger makes assignment to the primary key anywhere in the trigger code, that causes the session firing the trigger to take a lock on any child tables with a foreign key to this primary key. Even if the assignment is in for example an `if inserting` block and the trigger is fired by an `update` statement, such locks still happen unnecessarily. The issue is avoided by having one trigger for the insert containing the primary key assignment, and another trigger for the update. Or even better by handling the insert assignment as ´default on null´ clauses, so that only an `on update` trigger is needed.
+
+## Example (bad)
+
+``` sql
+create or replace trigger dept_br_iu
+before insert or update
+on departments for each row
+begin
+   if inserting then
+      :new.department_id := department_seq.nextval;
+      :new.created_date  := sysdate;
+   end if;
+   if updating then
+      :new.changed_date := sysdate;
+   end if;
+end;
+/
+```
+
+## Example (good)
+
+``` sql
+create or replace trigger dept_br_i
+before insert
+on departments for each row
+begin
+   :new.department_id := department_seq.nextval;
+   :new.created_date  := sysdate;
+end;
+/
+
+create or replace trigger dept_br_u
+before update
+on departments for each row
+begin
+   :new.changed_date := sysdate;
+end;
+/
+```
+
+## Example (best)
+
+``` sql
+alter table department modify department_id default on null department_seq.nextval;
+alter table department modify created_date  default on null sysdate;
+
+create or replace trigger dept_br_u
+before update
+on departments for each row
+begin
+   :new.changed_date := sysdate;
+end;
+/
+```

docs/9-appendix/appendix.md

@@ -118,7 +118,8 @@ n/a | 7460 | Try to define your packaged/standalone function deterministic if ap
 76 | 7510 | Always prefix ORACLE supplied packages with owner schema name. | Major |  |  |  |  |  |  | ✘ | 
 77 | 7710 | Avoid cascading triggers. | Major |  |  | ✘ |  |  |  |  | ✘
 n/a | 7720 | Never use multiple UPDATE OF in trigger event clause. | Blocker |  |  | ✘ |  | ✘ |  |  | ✘
-n/a | 7730 | Avoid multiple DML events per trigger if primary key is assigned in trigger. | Major |  | ✘ |  |  | ✘ |  |  | 
+n/a | 7730 | Avoid multiple DML events per trigger. | Minor |  |  | ✘ |  |  |  |  | ✘
+n/a | 7740 | Never handle multiple DML events per trigger if primary key is assigned in trigger. | Major |  | ✘ |  |  | ✘ |  |  | 
 n/a | 7810 | Never use SQL inside PL/SQL to read sequence numbers (or SYSDATE). | Major |  | ✘ | ✘ |  |  |  |  | 
 78 | 8110 | Never use SELECT COUNT(*) if you are only interested in the existence of a row. | Major |  | ✘ |  |  |  |  |  | 
 n/a | 8120 | Never check existence of a row to decide whether to create it or not. | Major |  | ✘ |  |  | ✘ |  |  |