Reported by a Lovable agent implementing CipherStash in a Lovable-hosted project. It discovered every fact below by hand, with ad-hoc psql queries, after an install had already failed and rolled back.
The gap
EQLInstaller.checkPermissions() (packages/cli/src/installer/index.ts:52-105) already asks most of the right questions — rolsuper, CREATE on database, CREATE on public, pgcrypto presence — but:
- It is not exposed as a command.
stash doctor (packages/cli/src/cli/registry.ts:209-211) diagnoses "native binaries, runtime" — not database role capability. There is no read-only "will this install work here, and if not, why" check.
- It does not check membership of
postgres, which on managed platforms is the only thing that actually fails (see the owner-scoped-grants issue). A role can pass every existing check and still abort the install.
Proposal
stash eql preflight (or extend stash doctor), read-only, run before anything is attempted:
current_user sandbox_exec
superuser no
member of postgres no <- blocks: ALTER DEFAULT PRIVILEGES FOR ROLE postgres
CREATE on database yes
CREATE on public yes
pgcrypto present
eql_v3 schema absent
eql_v3_internal absent
Each blocked row should name the statement it blocks and the remedy, not just report a boolean. The postgres-membership row is the one that matters: it turns a post-hoc rollback into a pre-flight sentence.
Implementation notes:
- Membership is
pg_has_role(current_user, 'postgres', 'MEMBER'), guarded for databases with no postgres role at all.
- Run it automatically at the head of
stash eql install so the operator gets the diagnosis without knowing to ask — the check is a handful of catalogue queries on a connection the installer opens anyway.
--json for agents.
Related: the owner-scoped-grants issue (the failure this predicts), and the TLS issue (preflight should also surface a cert-chain failure as such, rather than as a generic connect error).
Reported by a Lovable agent implementing CipherStash in a Lovable-hosted project. It discovered every fact below by hand, with ad-hoc
psqlqueries, after an install had already failed and rolled back.The gap
EQLInstaller.checkPermissions()(packages/cli/src/installer/index.ts:52-105) already asks most of the right questions —rolsuper,CREATEon database,CREATEonpublic,pgcryptopresence — but:stash doctor(packages/cli/src/cli/registry.ts:209-211) diagnoses "native binaries, runtime" — not database role capability. There is no read-only "will this install work here, and if not, why" check.postgres, which on managed platforms is the only thing that actually fails (see the owner-scoped-grants issue). A role can pass every existing check and still abort the install.Proposal
stash eql preflight(or extendstash doctor), read-only, run before anything is attempted:Each blocked row should name the statement it blocks and the remedy, not just report a boolean. The
postgres-membership row is the one that matters: it turns a post-hoc rollback into a pre-flight sentence.Implementation notes:
pg_has_role(current_user, 'postgres', 'MEMBER'), guarded for databases with nopostgresrole at all.stash eql installso the operator gets the diagnosis without knowing to ask — the check is a handful of catalogue queries on a connection the installer opens anyway.--jsonfor agents.Related: the owner-scoped-grants issue (the failure this predicts), and the TLS issue (preflight should also surface a cert-chain failure as such, rather than as a generic connect error).