From 46ca345ee5f33e905ff35f38d42fb88c0bd5853a Mon Sep 17 00:00:00 2001 From: Jason Novinger Date: Tue, 8 Sep 2026 11:52:24 -0500 Subject: [PATCH] Point plugin authors at ReinstallLtreeTriggers The release note told plugin authors to correct their own ltree triggers by applying InstallLtreeTriggers again. That works forwards, but reversing such a migration drops both triggers and their functions while the migration which first installed them stays applied, leaving the table with no path maintenance at all. ReinstallLtreeTriggers was added for this case and reverses to a no-op. Core's own corrective migrations already use it; the advice given to plugins should match. --- docs/release-notes/version-4.7.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/release-notes/version-4.7.md b/docs/release-notes/version-4.7.md index 5ddf085c0..d0b0de515 100644 --- a/docs/release-notes/version-4.7.md +++ b/docs/release-notes/version-4.7.md @@ -29,7 +29,7 @@ A rebuild rewrites every row of the named tables, locking those rows until it commits, so run it during a maintenance window. Should it report that a table contains rows unreachable from any root, the parent relationships themselves need correcting first: a rebuild walks down from the roots and would skip those rows. - Plugins which maintain their own `ltree` models via the `InstallLtreeTriggers` migration operation are affected in the same way, and their tables are not touched by the migrations above. Where such a database was restored from a dump, the plugin's cascade triggers are missing entirely; where it was upgraded in place, they carry the old definition and will be lost by its next dump. Either way, applying `InstallLtreeTriggers` again from a new plugin migration reinstalls them: as of this release the operation drops each trigger before recreating it, so it is safe to re-run. + Plugins which maintain their own `ltree` models via the `InstallLtreeTriggers` migration operation are affected in the same way, and their tables are not touched by the migrations above. Where such a database was restored from a dump, the plugin's cascade triggers are missing entirely; where it was upgraded in place, they carry the old definition and will be lost by its next dump. Either way, a new plugin migration applying `ReinstallLtreeTriggers` (passing the same `name_column` as the original) installs the corrected definitions. Use that operation rather than `InstallLtreeTriggers`: both drop each trigger before recreating it, so either works going forwards, but reversing the corrective migration should not undo the original installation. `InstallLtreeTriggers` reverses by dropping both triggers and their functions, which would leave the table with no path maintenance while the migration that first installed them remains applied. `ReinstallLtreeTriggers` reverses to a no-op instead. ---