pgclone 4.4.1 — Type-aware data masking
Bug-fix release addressing issue #17. (Merged via PR #20 but not previously tagged.)
Highlights
A masking strategy emits a value of a fixed kind — text (email/name/phone/partial/hash), an integer (random_int), SQL NULL, or a caller literal (constant). When that value was fed into a column whose type could not parse it, the clone aborted deep inside the streaming COPY. The trigger in the report: discover_sensitive() matched a boolean column (base_income_replacement_allow) against the %income% financial pattern and suggested random_int, producing:
ERROR: pgclone: COPY completed with error:
ERROR: invalid input syntax for type boolean: "60629"
Now every mask-application site checks the column's pg_type.typcategory first and skips an incompatible mask with a WARNING (leaving the column unchanged) instead of corrupting the COPY stream:
- text masks fit string columns;
random_intfits numeric or string columns;null/constantare left to the server. pgclone.discover_sensitive()no longer suggests a mask incompatible with a column's type.pgclone.masking_report()flags such a column for manual review.pgclone.mask_in_place()skips incompatible rules (clear no-op message when all are skipped);pgclone.create_masking_policy()leaves the column unmasked, preserving its type.
Compatibility
- No SQL signature changes — the fix is entirely in the C masking engine.
sql/pgclone--4.4.0--4.4.1.sqlonly bumps the installed version. - Behavior change is limited to masks that previously crashed the clone; masks that already worked are unaffected.
- Synchronous paths only. Identical behavior on PostgreSQL 14–18.
Upgrade
ALTER EXTENSION pgclone UPDATE TO '4.4.1';Tests
pgTAP group 26 (8 tests, plan 87 → 95) plus a test_schema.flags fixture (a boolean income_verified column matching %income%).
Full changelog: see CHANGELOG.md ([4.4.1]).