Context
Follow-up from #375, which made the two SEM btree operator classes (eql_v3_internal.ore_block_256_operator_class, eql_v3_internal.ore_cllw_ops) install conditionally: a DO block catches insufficient_privilege (SQLSTATE 42501) and skips class creation with a NOTICE, so the single release/cipherstash-encrypt.sql installer runs on managed Postgres (Supabase / non-superuser) as well as self-managed (superuser).
Gap
The skip branch is only covered by manual verification against a live Supabase instance (documented in the #375 description). The automated SQLx suite runs as a superuser (local Docker postgres), so it only ever exercises the created path:
tests/sqlx/tests/ore_cllw_v3_opclass_tests.rs asserts ore_cllw_ops is DEFAULT FOR TYPE — i.e. the opclass exists.
Nothing asserts that:
- the installer commits when the operator classes cannot be created (non-superuser role),
- the
EXCEPTION WHEN insufficient_privilege handler fires (the two "skipped" NOTICEs are emitted), and
- only
insufficient_privilege is swallowed — any other DDL error still propagates and fails the install loudly.
If a future change broadened the caught exception, narrowed it, or reordered the DDL so the family/class creation moved outside the guarded block, the superuser matrix would stay green while Supabase installs silently regressed.
Suggested approach
Add a regression test that installs (or runs just the two operator_class.sql blocks) under a non-superuser role, asserting:
- the statement commits without error,
pg_opclass contains 0 of the two custom classes afterward, and- (ideally) the expected
NOTICE is emitted.
This needs a non-superuser role in the test harness, which the current matrix doesn't set up — so it's a small harness addition, not a one-line test. A negative test that a non-insufficient_privilege DDL failure still propagates would also be valuable.
Non-goals
Not blocking — #375 is verified end-to-end manually and is safe to merge. This issue just converts that manual check into CI coverage.
Context
Follow-up from #375, which made the two SEM btree operator classes (
eql_v3_internal.ore_block_256_operator_class,eql_v3_internal.ore_cllw_ops) install conditionally: aDOblock catchesinsufficient_privilege(SQLSTATE 42501) and skips class creation with aNOTICE, so the singlerelease/cipherstash-encrypt.sqlinstaller runs on managed Postgres (Supabase / non-superuser) as well as self-managed (superuser).Gap
The skip branch is only covered by manual verification against a live Supabase instance (documented in the #375 description). The automated SQLx suite runs as a superuser (local Docker
postgres), so it only ever exercises the created path:tests/sqlx/tests/ore_cllw_v3_opclass_tests.rsassertsore_cllw_opsisDEFAULT FOR TYPE— i.e. the opclass exists.Nothing asserts that:
EXCEPTION WHEN insufficient_privilegehandler fires (the two "skipped" NOTICEs are emitted), andinsufficient_privilegeis swallowed — any other DDL error still propagates and fails the install loudly.If a future change broadened the caught exception, narrowed it, or reordered the DDL so the family/class creation moved outside the guarded block, the superuser matrix would stay green while Supabase installs silently regressed.
Suggested approach
Add a regression test that installs (or runs just the two
operator_class.sqlblocks) under a non-superuser role, asserting:pg_opclasscontains 0 of the two custom classes afterward, andNOTICEis emitted.This needs a non-superuser role in the test harness, which the current matrix doesn't set up — so it's a small harness addition, not a one-line test. A negative test that a non-
insufficient_privilegeDDL failure still propagates would also be valuable.Non-goals
Not blocking — #375 is verified end-to-end manually and is safe to merge. This issue just converts that manual check into CI coverage.