Fix ordering of DROP TRIGGER statements in the filtered schema

[tsg]

Description

In a similar issue with #573 we're seeing error of this form:

ERROR: relation "public.table" does not exist

Which seem to come from DROP TRIGGER statmenets in the filtered schema like:

DROP TRIGGER IF EXISTS trigger_name ON public.table;

because it's called before public.table is created.

Related Issue(s)

• Fixes #(issue number)
• Closes #(issue number)
• Related to #(issue number)

Type of Change

Please select the relevant option(s):

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📚 Documentation update
• 🔧 Refactoring (no functional changes)
• ⚡ Performance improvement
• 🧪 Test coverage improvement
• 🔨 Build/CI changes
• 🧹 Code cleanup

Changes Made

Testing

• Unit tests added/updated
• Integration tests added/updated
• Manual testing performed
• All existing tests pass

Checklist

• Code follows project style guidelines
• Self-review completed
• Code is well-commented
• Documentation updated where necessary

Additional Notes

[github-actions]

Merging this branch will not change overall coverage

Impacted Packages	Coverage Δ	🤖
github.com/xataio/pgstream/pkg/snapshot/generator/postgres/schema/pgdumprestore	90.14% (ø)

---

Coverage by file

Changed files (no unit tests)

Changed File	Coverage Δ	Total	Covered	Missed	🤖
github.com/xataio/pgstream/pkg/snapshot/generator/postgres/schema/pgdumprestore/snapshot_pg_dump_restore_generator.go	83.71% (ø)	264	221	43

Please note that the "Total", "Covered", and "Missed" counts above refer to code statements instead of lines of code. The value in brackets refers to the test coverage of that file in the old version of the code.

[eminano]

This shouldn't happen. The drop statements are coming from the clean stage of the dump. The order should be valid unless the clean is enabled and the table doesn't exist, but even in that case, it shouldn't be preventing the dump, those errors should be ignored.

Can you share more details about what triggers this?