SQL inheritance tutorial, addendum: PK and trigger issues

content/tutorials/sql_inheritance/index.md

@@ -36,6 +36,14 @@ However, an adequate logical representation of the data type hierarchy is both l
 Thus, inheritance might be an option to consider for joining TODO lists or field activities.
 I will herein explore the basic implementation, in practical use, and also assert which use cases this technique is good for.
 
+
+{{% callout note %}}
+
+If you would like to get started with SQL and R: the [INBO Coding Club session](https://coding-club.inbo.be/sessions/index.html) of August 27th, 2026 ([slides](https://coding-club.inbo.be/sessions/20260827_sql_in_r.html)) covered the topic.
+
+{{% /callout %}}
+
+
 # PostgreSQL installation (optional)
 
 To get our hands on the examples below, running some kind of postgreSQL server is required.
@@ -618,6 +626,10 @@ Even if the computational load would be equivalent in both the implementations I
 the use of `INHERITS` gives some extra conceptual structure to the data which has documentational value.
 
 Inheritance is not a general solution, and should be carefully considered.
+A breaking limitation for some use cases, and probably the reason why the postgreSQL implementation of inheritance is not abundantly used, is that **primary keys and triggers are not inherited**. 
+Worse even, inherited tables can lead to primary key duplicates (more leads [on this comment](https://github.com/qgis/QGIS/issues/21962#issuecomment-495853940)).
+I personally can work around that by defining new primary keys in the child tables (`activity_id` in `Activities`, and `pushup_id` in `PushUps`), and by having extra measures in place to enforce PK integrity.
+Triggers simply have to be applied to all child tables individually, even if they only affect parent table fields.
 Keep in mind that postgreSQL inheritance is *structural* inheritance (I think of it as automatic `UNION`s which happen when I query the common fields; `NATURAL FULL JOIN`s play nicely into that).
 Advanced functionality is available with other `JOIN`s, Views, and `UPDATE` Rules.
 

content/tutorials/sql_inheritance/index.qmd

@@ -65,6 +65,15 @@ Thus, inheritance might be an option to consider for joining TODO lists or field
 I will herein explore the basic implementation, in practical use, and also assert which use cases this technique is good for.
 
 
+```{=markdown}
+{{% callout note %}}
+```
+If you would like to get started with SQL and R: the [INBO Coding Club session](https://coding-club.inbo.be/sessions/index.html) of August 27th, 2026 ([slides](https://coding-club.inbo.be/sessions/20260827_sql_in_r.html)) covered the topic.
+
+```{=markdown}
+{{% /callout %}}
+```
+
 # PostgreSQL installation (optional)
 
 To get our hands on the examples below, running some kind of postgreSQL server is required.
@@ -615,6 +624,10 @@ the use of `INHERITS` gives some extra conceptual structure to the data which ha
 
 
 Inheritance is not a general solution, and should be carefully considered.
+A breaking limitation for some use cases, and probably the reason why the postgreSQL implementation of inheritance is not abundantly used, is that **primary keys and triggers are not inherited**. 
+Worse even, inherited tables can lead to primary key duplicates (more leads [on this comment](https://github.com/qgis/QGIS/issues/21962#issuecomment-495853940)).
+I personally can work around that by defining new primary keys in the child tables (`activity_id` in `Activities`, and `pushup_id` in `PushUps`), and by having extra measures in place to enforce PK integrity.
+Triggers simply have to be applied to all child tables individually, even if they only affect parent table fields.
 Keep in mind that postgreSQL inheritance is *structural* inheritance (I think of it as automatic `UNION`s which happen when I query the common fields; `NATURAL FULL JOIN`s play nicely into that).
 Advanced functionality is available with other `JOIN`s, Views, and `UPDATE` Rules.