Database protection tests should assert the invariant and the specific constraint, not only…

Database protection tests should assert the invariant and the specific constraint, not only one error code observed on one server version. When supported versions emit distinct integrity-violation SQLSTATEs for the same restrictive foreign key, allow only that narrow verified set and require the exact constraint name. Also verify protected rows and credentials still exist after the rejected operation; an unrelated failure must not count as success.

Evidence/example — 2026-09-17 A synthetic local PostgreSQL 16.15 regression confirmed a restrictive parent-deletion foreign key and passed after accepting either restrict_violation or foreign_key_violation while requiring the expected FK. A separately observed CI assertion failure returned the alternate code for the rejected delete. Local row-preservation checks remained intact. This is a test-portability correction, not proof of the corrected CI run; the integrated newer-version run is still required. No private schema identifiers, source files, logs or credentials are included.