Spun off from #179 (deliberately deferred — no known users of PME encryption today).
Current state (safe, documented in COMPATIBILITY.md)
The change feeds degrade on encrypted (PME) catalogs rather than returning wrong data:
ducklake_table_changes works for inserted rows, but UPDATEs surface as plain inserts (no preimage/postimage pairing), pure deletes are missing, rowid is emitted all-NULL, and merged partial files reachable only via partial_max are dropped.- A window whose only changes are deletes has no data file to detect encryption from, so it fails at read time.
ducklake_table_deletions has no decryption wiring at all and cannot read encrypted files.
Official DuckLake's CDC binds to the regular table scan, which decrypts — so it produces real rowids and full change-sets on encrypted catalogs.
Work
- Thread per-file encryption keys into the CDC footer probes (
detect_embedded_cdc_names and the deletions-feed equivalent) and all CDC scans (insert scans, delete-source scans, delete-file scans) — the regular table scan already does this (with_file_decryption_properties), so the pattern exists.
DeleteFileChange carries no encryption fields: add data-file and delete-file keys to the delete-file queries across the five provider copies (shared/DuckDB, SQLite, PostgreSQL, MySQL, multicatalog).- Remove the
any_encrypted gates in table_changes.rs and the COMPATIBILITY.md caveat.
- Add an encrypted scenario to the differential harness (
tests/cdc_differential_tests.rs) — the installed extension supports encrypted attach, so it can live-diff.
All of it is inert for unencrypted catalogs (keys are NULL; same code paths as today).
Spun off from #179 (deliberately deferred — no known users of PME encryption today).
Current state (safe, documented in COMPATIBILITY.md)
The change feeds degrade on encrypted (PME) catalogs rather than returning wrong data:
ducklake_table_changesworks for inserted rows, but UPDATEs surface as plaininserts (no preimage/postimage pairing), pure deletes are missing,rowidis emitted all-NULL, and merged partial files reachable only viapartial_maxare dropped.ducklake_table_deletionshas no decryption wiring at all and cannot read encrypted files.Official DuckLake's CDC binds to the regular table scan, which decrypts — so it produces real rowids and full change-sets on encrypted catalogs.
Work
detect_embedded_cdc_namesand the deletions-feed equivalent) and all CDC scans (insert scans, delete-source scans, delete-file scans) — the regular table scan already does this (with_file_decryption_properties), so the pattern exists.DeleteFileChangecarries no encryption fields: add data-file and delete-file keys to the delete-file queries across the five provider copies (shared/DuckDB, SQLite, PostgreSQL, MySQL, multicatalog).any_encryptedgates intable_changes.rsand the COMPATIBILITY.md caveat.tests/cdc_differential_tests.rs) — the installed extension supports encrypted attach, so it can live-diff.All of it is inert for unencrypted catalogs (keys are NULL; same code paths as today).