row_filters: optional FK-aware / related-row retain (cascade keep/delete)

[cursor]

Summary

row_filters are per-table. Retaining recent parents (e.g. listing_order where created is recent) does not automatically retain/delete related children (orderitem, shipments, returns, …). Downstream restores often need session_replication_role = replica (or similar) to load orphan-trimmed graphs, and the anonymised DB still contains dangling FKs unless cleaned up separately.

Ask

Consider an opt-in way to express related-row policy, for example:

[row_filters."public.listing_order"]
retain = [{ column = "created", op = "gte_datetime", value = "2025-02-14" }]

[[row_filters."public.listing_order".cascade]]
child_table = "public.listing_orderitem"
child_fk = "order_id"
parent_pk = "id"
# keep child rows whose parent was retained; drop others

Or a simpler v1: document that Dumpling won’t do this and recommend post-restore SQL — but if it’s in scope, even parent→child retain cascading for COPY dumps would remove a major footgun for trimmed anonymised clones.

Non-goals (fine to defer)

• Full topological sort of arbitrary FK graphs
• Cross-schema discovery from live DB (dump-only tool)

Context

Reskinned anonymised prod copy trims bulky/recent order data in-stream; orphans are tolerated at load time. FK-aware retain would let us shrink copies further without integrity gymnastics. Related: temporal gte for timestamps (companion issue).