You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
refactor(test): dedup ORE/OPE fixtures and ordering test helpers
Collapse the two near-identical ORE/OPE fixture-table DO blocks in
schema.sql into one kind-parameterized loop, fold the OPE ordering tests
into a shared run_order_test helper, and delegate the ORE text-ordering
helpers to ore_order_generic. Also add guidance on choosing ope vs ore
to the encrypted-index docs. Addresses PR review feedback.
The first SQL statement adds a `match` index, which is used for partial matches with `LIKE`.
230
230
The second SQL statement adds an `ore` index, which is used for ordering with `ORDER BY` and range comparisons (`<`, `<=`, `>`, `>=`).
231
-
The third SQL statement adds an `ope` index, which supports the same range and ordering operators as `ore` and is a drop-in alternative — pick `ope` or `ore` per column, not both.
231
+
The third SQL statement adds an `ope` index, which supports the same range and ordering operators as `ore`.
232
+
233
+
`ore`and `ope` are alternatives for range and ordering queries — add one or the other to a column, not both. `ore` is the recommended default. `ope` produces ciphertexts that sort under PostgreSQL's native byte ordering, which makes ordering and range scans cheaper, but as an order-preserving scheme it reveals more about the relative order of stored values than `ore` does. Choose based on your performance and threat-model requirements; see the [EQL `INDEX` documentation](https://github.com/cipherstash/encrypt-query-language/blob/main/docs/reference/INDEX.md) for the full tradeoffs.
0 commit comments