Index: openacs-4/packages/file-storage/tcl/file-storage-procs.tcl
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/file-storage/tcl/file-storage-procs.tcl,v
diff -u -r1.90.2.18 -r1.90.2.19
--- openacs-4/packages/file-storage/tcl/file-storage-procs.tcl	7 Apr 2021 20:07:20 -0000	1.90.2.18
+++ openacs-4/packages/file-storage/tcl/file-storage-procs.tcl	9 Apr 2021 17:48:27 -0000	1.90.2.19
@@ -1067,8 +1067,39 @@
 
     content::item::set_live_revision -revision_id $revision_id
 
-    db_exec_plsql update_last_modified ""
+    # apisano - This is what we had before (postgres code):
+    # begin
+    # perform acs_object__update_last_modified
+    # (:parent_id,:creation_user,:creation_ip);
+    # perform
+    # acs_object__update_last_modified(:item_id,:creation_user,:creation_ip);
+    # return null;
+    # end;
+    # It has been translated with the recursive query below, which
+    # conserves the same logics: update modification metadata for the
+    # whole context hierarchy of item and parent. However, I wonder if
+    # there is really need for all of this...
+    db_dml update_last_modified {
+        with recursive context_hierarchy as (
+            select object_id, context_id
+              from acs_objects
+             where object_id in (:item_id, :parent_id)
 
+            union
+
+            select p.object_id, p.context_id
+              from acs_objects p,
+                   context_hierarchy c
+             where p.object_id = c.context_id
+               and c.context_id <> 0
+        )
+        update acs_objects set
+          modifying_user = :creation_user,
+          modifying_ip   = :creation_ip,
+          last_modified  = current_timestamp
+        where object_id in (select object_id from context_hierarchy)
+    }
+
     if {[string is false $suppress_notify_p]} {
         fs::do_notifications \
             -folder_id $parent_id \