Skip to content

pgclone 4.4.1 — Type-aware data masking

Choose a tag to compare

@valehdba valehdba released this 01 Jul 19:34

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_int fits numeric or string columns; null/constant are 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.sql only 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]).