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
{{ message }}
Repository navigation
Commit 35b382d
Browse filesBrowse the repository at this point in the historyBrowse files
feat(stack-encrypt)!: let an inverted Between range through, as SQL does
A `Between` whose low bound is above its high bound was refused with
`TermError::InvertedRange` before either term was derived. SQL's own
`BETWEEN` refuses nothing: `x BETWEEN 20 AND 10` is a valid query that
matches no row, and an encrypted range now behaves the same way. The
empty result leaks nothing and corrupts nothing, so a refusal bought
little.
It would also cost more than it buys once text and floats are ordered.
Judging their ranges correctly means reproducing, before encryption, the
order the index compares in: text by its fold, floats by their canonical
encoding. That order belongs to the ORE crates, not to this one.
So `TermError::InvertedRange` (code `stack_encrypt::inverted_range`)
goes, with the typed path's `lo > hi` check (and the `PartialOrd` bound
`op::Ordered` carried for it) and the data path's `integer_order`. The
variant is under [Unreleased] and never shipped.
Copy file name to clipboardExpand all lines: packages/stack-encrypt/docs/adr/0009-operators-select-the-index-and-a-query-term-is-not-the-stored-term.md
+6-3Lines changed: 6 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -572,9 +572,12 @@ the ranked loop is worth packaging; it is deferred, not refused.
572
572
573
573
`cipher.query(op::Between, &(lo, hi)).on(&plan)` produces one term,
574
574
`sem::RangeQuery`, carrying the index's term for each bound (the ORE left
575
-
ciphertexts, once block ORE lands), inclusive at both ends, and the client
576
-
refuses `lo > hi` (`TermError::InvertedRange`) before either term is
577
-
derived; `(v, v)` is one value. One call derives both bounds, under one
575
+
ciphertexts, once block ORE lands), inclusive at both ends; `(v, v)` is one
576
+
value. The client does not refuse `lo > hi`: as SQL's `BETWEEN`, such a
577
+
range matches nothing. Judging it would mean reproducing, before
578
+
encryption, the order the index compares in (text by its fold, floats by
579
+
their canonical encoding), which belongs to the ORE crates. One call
580
+
derives both bounds, under one
578
581
context, so a caller cannot pair a bound from one column with a bound from
579
582
another. The ordering operators are answered over the integer types and
580
583
text (`op::Ordered`), by the ORE index by default and by OPE through
0 commit comments