No SDK can build an EQL v4 range operand for eql_v4.between — range bindings implement no EncryptFrom #1286

Background

EQL (Encrypt Query Language) is the SQL library we install into a customer's PostgreSQL database. EQL v4 is the copy of it that Stack Encrypt, our Rust encryption engine, writes into. #1243 gives EQL v4 a range query: eql_v4.between(column, range), where range is one value holding both bounds, {"v":4,"i":{...},"lo":<term>,"hi":<term>}. It is cast to a range query domain such as eql_v4.query_integer_range_ope. The Rust bindings in eql_bindings::v4 have one struct per range domain (IntegerRangeOpeQuery, DateRangeOreQuery, …), and the Go SDK has the matching []byte types.

Problem

No SDK can build a range value yet. A customer who wants BETWEEN on an encrypted column has the SQL for it, but nothing produces its operand. So they write two predicates (col >= $1 AND col <= $2), which is the shape ADR-0009 decision 7 removed: the two bounds travel separately and can be paired across columns.

Every single-bound query operand that has a stored term Stack Encrypt can derive already derives EncryptFrom<T>, e.g. DateOrdOpeQuery: EncryptFrom<NaiveDate>. The range structs implement neither EncryptFrom nor DecryptInto, for these reasons:

• DecryptInto should never apply. A range is a query operand, and no query operand decrypts.
• #[derive(EncryptFrom)] can't describe a range. plaintext = T derives every field from the whole value, so lo and hi would get the same bound. struct = T derives each field under its own context, (ctx, "lo") and (ctx, "hi"), but a bound must be derived under the column's own context or it won't compare against the stored term. A range needs a hand-written EncryptFrom<(S, S)>, with each bound from OpeCllw: EncryptFrom<S> (packages/eql/crates/eql-bindings/src/encryption.rs:397) under the caller's context.
• ORE ranges can't be built yet. OreBlock256 has no EncryptFrom until block ORE (order-revealing encryption) lands (stashgen refuses TextOrdOre and TextSearchOre — EQL stores block ORE terms and the engine derives CLLW ORE #1132, feat(eql)!: produce the block ORE EQL v4 types through ore-rs 6-bit block ORE #1280). stashgen refuses TextOrdOre and TextSearchOre — EQL stores block ORE terms and the engine derives CLLW ORE #1132 also still has to settle whether a query bound is a full ciphertext or a left ciphertext.
• The dynamic path refuses it. stack_encrypt::dynamic::query_term returns Error::Internal for a between on a field that names an EQL type (packages/stack-encrypt/src/dynamic/query.rs:766-768). The target table has a query_sql_domain for the single-bound query twin and nothing for a range (packages/eql/crates/eql-bindings/src/encryption/targets.rs:128), so stashgen and the Go SDK can't map an ordered type to its range type.

Proposal

1. Have eql-codegen emit EncryptFrom<(S, S)> for the nine …RangeOpeQuery structs, with S the family's plaintext. Each bound is the OpeCllw the single-bound …OrdOpeQuery derives, under the same context. Add a test that a range built this way finds the same rows in PostgreSQL as two single-bound queries.
2. Add a range domain to the target table (range_query_sql_domain, per ordering term), and generate it into the Go Types table.
3. In query_term, build the {v, i, lo, hi} envelope for between on an EQL target instead of returning Error::Internal.
4. Once block ORE lands and stashgen refuses TextOrdOre and TextSearchOre — EQL stores block ORE terms and the engine derives CLLW ORE #1132 settles the bound shape, do the same for the nine …RangeOreQuery structs.

Steps 1 to 3 can ship before step 4.

Relationship to other work

• feat(eql): give EQL v4 range query domains and eql_v4.between #1243 adds the SQL, the bindings structs and the Go types. Its review asked why the structs implement neither trait; this issue is the answer and the follow-up.
• stashgen refuses TextOrdOre and TextSearchOre — EQL stores block ORE terms and the engine derives CLLW ORE #1132 and feat(eql)!: produce the block ORE EQL v4 types through ore-rs 6-bit block ORE #1280 cover block ORE, which step 4 waits for.