Reported by a Lovable agent implementing CipherStash in a Lovable-hosted project.
The ORE-unavailable case should be detected at install time and reported once ("this platform will fall back to OPE ordering"), rather than surfacing only when a column is cast — and stash eql install should pick the OPE domains automatically in Supabase mode.
What is true today
The EQL v3 bundle wraps CREATE OPERATOR CLASS for the ORE opclass in a guarded DO block that swallows insufficient_privilege (42501) and continues. On managed Postgres — Supabase included — the install therefore succeeds with the opclass absent. The public.eql_v3_*_ord_ore domains themselves remain present and usable as column types; what is lost is index-backed ordering (verified in #759).
The install says nothing about this. EQLInstaller.install() (packages/cli/src/installer/index.ts:169-194) runs the bundle and returns. The operator learns about it later — when an ordered query is slow, or, in the reporter's case, when something on the ORE path errored at query time.
Proposal
1. Detect and report once, at install. After the bundle runs, check whether the ORE operator class was created. If it was not, print a single line naming the consequence and the remedy:
ORE operator class not created (requires superuser; unavailable on this platform).
Ordered queries will use OPE ordering. Prefer types.Ord — it indexes on any role.
This is one pg_opclass lookup. Also expose it in stash eql status, so the answer survives past the install output, and in the preflight check (sibling issue) so it can be predicted rather than discovered.
2. Default schema scaffolding to the OPE domains on managed Postgres. stash eql install scaffolds stash.config.ts when missing; stash init builds the schema and already detects the provider (packages/cli/src/commands/init/steps/build-schema.ts:38 — detectSupabase(databaseUrl)). Where that detection says Supabase (or ORE detection says the opclass is absent), ordered columns should scaffold as Ord, not OrdOre, and say why in a comment. Choosing OrdOre on a platform that cannot index it is never the right default.
stash eql validate already flags an _ord_ore column on a database whose install could not create the opclass — this is the same knowledge, moved to where the choice is made rather than where it is audited.
Related
Reported by a Lovable agent implementing CipherStash in a Lovable-hosted project.
What is true today
The EQL v3 bundle wraps
CREATE OPERATOR CLASSfor the ORE opclass in a guardedDOblock that swallowsinsufficient_privilege(42501) and continues. On managed Postgres — Supabase included — the install therefore succeeds with the opclass absent. Thepublic.eql_v3_*_ord_oredomains themselves remain present and usable as column types; what is lost is index-backed ordering (verified in #759).The install says nothing about this.
EQLInstaller.install()(packages/cli/src/installer/index.ts:169-194) runs the bundle and returns. The operator learns about it later — when an ordered query is slow, or, in the reporter's case, when something on the ORE path errored at query time.Proposal
1. Detect and report once, at install. After the bundle runs, check whether the ORE operator class was created. If it was not, print a single line naming the consequence and the remedy:
This is one
pg_opclasslookup. Also expose it instash eql status, so the answer survives past the install output, and in the preflight check (sibling issue) so it can be predicted rather than discovered.2. Default schema scaffolding to the OPE domains on managed Postgres.
stash eql installscaffoldsstash.config.tswhen missing;stash initbuilds the schema and already detects the provider (packages/cli/src/commands/init/steps/build-schema.ts:38—detectSupabase(databaseUrl)). Where that detection says Supabase (or ORE detection says the opclass is absent), ordered columns should scaffold asOrd, notOrdOre, and say why in a comment. ChoosingOrdOreon a platform that cannot index it is never the right default.stash eql validatealready flags an_ord_orecolumn on a database whose install could not create the opclass — this is the same knowledge, moved to where the choice is made rather than where it is audited.Related
stash-encryption: the_ord_oredomains are not disabled on managed Postgres — only the opclass is skipped #759 — thestash-encryptionskill states the_ord_oredomains are disabled on managed Postgres. They are not; only the opclass is skipped. Any messaging added here must use the corrected model.*_ord_oredomains #629 — superuser-only ORE SQL coverage suite.OrdvsOrdOretrade is exactly what that table needs to make legible.