Repository navigation
feat(eql-bindings): produce Smallint and SmallintEq from i16 - #1267
Conversation
🦋 Changeset detectedLatest commit: 337e882 The changes in this PR will be included in the next version bump. This PR includes changesets to release 12 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
coderdan
left a comment
coderdan
left a comment
There was a problem hiding this comment.
Review at 48c44de. No blocking problems. The range checks, the equality term and the SQL shapes are right. There are two test gaps, a changeset conflict that will certainly happen, and two stale comments.
Findings (most severe first)
-
Medium: no row the Go SDK sealed as
SmallintorSmallintEqreaches Rust or PostgreSQL, and nothing freezes the smallint stored format (tally.go, inline).fixtures/README.mdsaysv4_rows.jsonandstored_v4_rows_v1.jsonhold "one value of every producible EQL v4 type". That is no longer true. Here is what goes wrong: a later change to how the guest seals a smallint leaf passes the Go round trip and thetallyquery fixture. The equality term is the same at every integer width by design, so the byte match on the term can't see the width. The frozen-rows guard was built to catch exactly that kind of change, and it doesn't cover these two types. #1266 handles the same problem forRankingby adding a Go-writtenv4_ordered_rows.jsonthat Rust opens and inserts into PostgreSQL. Do the same forTally, and either reword the README line or freeze a smallint row set. -
Low: the changeset will conflict with #1266 (inline). Both PRs rewrite the same single-line paragraph of
.changeset/eql-v4-bindings.mdfrom the same base blob (88887e454), so whichever merges second gets a textual conflict. #1266 targetsfeat/stack-encrypt-order-keys, so the conflict arrives when it rebases ontonext. A separate.changeset/eql-v4-smallint.md('@cipherstash/eql': minor, one sentence) avoids it. It would also clear the changeset-bot "No Changeset found" warning on this PR, which appears because the PR only edits an existing file. The package choice is right:@cipherstash/eqlis the lockstep vehicle for theeql-bindingscrate,types:checkshows the TypeScript output is unchanged, and the Go module isn't released through Changesets (its CHANGELOG is updated). -
Low: the Go test covers only one of the refusal paths (inline). It checks a codec write above the range. It doesn't check the lower bound (
MinInt16 - 1), an out-of-rangeWide.Eqquery, the single-fieldWide.Encrypt, or that the error names the field. I checked these by hand with a throwaway test against the deterministic EQL guest, and all of them behave correctly:Wide.Eq(MaxInt16+1)givesgensupport: wide: cipherstash: malformed input: a value does not fit the field's kind int16.EncryptTallywithWide: MinInt16-1gives... field "wide": ... does not fit the field's kind int16.
widened_test.gopins both bounds and the query path forIntegerEq. Mirroring it here would keep the smallint path pinned ifgensupportchanges. -
Nit: two leftovers of the stale premise this PR corrects (inline). The doc comment on
plaintext_of(bindings.rs:366) still says "Nonefor a family the engine's value enum has no kind for". The testthe_producible_types_are_the_unordered_ones_the_value_enum_carries(tests/targets.rs:567) is named after the same premise.
What I checked and found correct
- Range enforcement from Go. stashgen declares every built-in integer field stored as
Smallint/SmallintEqwith kindgensupport.Int16(seetally_stash.go, where theint32fieldwideis declared asInt16).asKindandintegerAsrange-check withMinInt16/MaxInt16on the codec write, onField.Encryptand onField.Term/Range. A value outside the range is refused withErrEncodingand the field's name; it is never truncated. Opening widens back into the field's Go type throughGet[int32]. The guest's by-name dispatch also refuses any frame that isn't exactlyint16, so the host can't send a wider leaf. - Equality term.
SmallintEq(v)produces the samehmasIntegerEq(v)andBigintEq(v)under one column. That is ADR-0002's single integer equality domain, and the column identifier keeps terms from different columns apart. With a throwaway local assertion I also confirmed the terms agree across widths for negative values and the extremes (-1,-300,i16::MIN,i16::MAX), so there is no sign-extension mismatch, and thatSmallintEq(-1)differs fromIntegerEq(65535). - SQL.
public.eql_v4_smallintrequiresv/i/cand_eqaddshm, withv = 4.eql_v4.eq_termcompareshm. The generated structs and the envelope assertions (c,i,vandc,hm,i,v) match. I didn't run the ignored PostgreSQL test myself; the PR description says it passed against PostgreSQL 17.5. - The new stashgen message is accurate. Stack Encrypt's
ValueKindhasDate,TimestampandDecimal, and the Go SDK hasrecord.Date,TimestampandDecimal. So "the engine and the Go SDK carry the kind" is true, and #1130 is the umbrella issue for these types.jsonis caught by an earlier branch, so only date, timestamp and numeric reach the new wording, and the codegen test pins all three across""/eq/ord. - Generated code drift. None.
types:checkregenerated everything and left the tree clean, and so didgo generate ./....
Checks run (no credentials needed)
packages/eql:mise run test:codegenandmise run types:check(clean tree afterwards);cargo test --locked -p eql-encryption-tests: all passed, PostgreSQL tests ignored;cargo clippy --locked -p eql-bindings -p eql-encryption-tests -p eql-codegen --all-features --all-targets -D warnings: clean.
- All five guests built (including
wasm:guest:build:eql:deterministic). Then, inlanguages/golang:go generate ./...: no diff;go vet ./...: clean;go test ./...: all packages pass, includingTestV4SmallintFieldsSealAndOpenBack.
The engine and the Go SDK both carry the int16 kind now, so the smallint family's storage and equality types need only eql-bindings to name a plaintext: i16 joins the sealed Plaintext set and plaintext_of, and the two domains join ENCRYPTION_DOMAINS. SmallintEq's term is the integer equality term, one per value whatever the width, so a smallint shares it with an integer of the same value under the same column. The date, timestamp and numeric families no longer say the engine has no kind for them, which stopped being true when the kinds landed. What they wait for is a choice of Rust plaintext type, and the reason says so. Tests: round trips through both entry points, the shared equality term, a value of another width refused by name and an i32 that does not fit refused on open, and in PostgreSQL `=` on SmallintEq (including both extremes) with the storage-only column blocked. v4_queries.json gains a SmallintEq query for the Go SDK.
48c44de to
1838018
Compare
coderdan
left a comment
coderdan
left a comment
There was a problem hiding this comment.
Incremental re-review of 48c44de..1838018: the amended d5184c2 plus the new 1838018.
Prior findings (review)
- Medium, no Go-sealed smallint row reaches Rust or PostgreSQL, and the README overclaims: fixed as asked.
v4_smallint_rows.jsonis Go-sealed.smallint_rows_the_go_sdk_sealed_open_in_rustopens all three fields ati16, includingwide, theint32field.postgres_stores_and_queries_smallint_rows_the_go_sdk_sealedputs the rows intoeql_v4_smallint/eql_v4_smallint_eqcolumns, and=with thetallyquery returns rows 1 and 3, not row 2. The README now says these rows are not frozen yet, so it no longer claims they are. The ignored test lives inv4_types, whichtest:encryption:postgresalready loops over, sotest-eql.ymlruns it. One gap is left in how CI hands rows from Go to Rust (inline below). - Low, changeset conflict with #1266: fixed. The entry moved to
.changeset/eql-v4-smallint.md. A trialgit merge-treeagainst #1266's head (82ab168) shows no conflict in.changeset/.fixtures/README.mdandtests/v4_types.rsmerge cleanly too. The conflicts left are in files both PRs regenerate or edit on purpose:eql_gen.go,v4/targets.rs, eql-codegen, the guest'stargets.rs,native_ops.rs, and the Go and eql-bindings docs. Those are expected for two PRs that both make types producible. - Low, refusal coverage: fixed. Both bounds now go through
EncryptTally,Wide.EncryptandWide.Eq, and the bounds themselves are accepted. I printed the errors. All three name the field (field "wide": ... does not fit the field's kind int16), so thestrings.Contains(..., "wide")check is not passing by accident. - Nit, wording that says the engine lacks a kind: fixed. The
plaintext_ofdoc and thetargets.rstest name are reworded, and grep finds no other copies in the touched files.
New findings
- Low: the smallint rows have no hand-off of today's rows from Go to Rust, unlike
v4_rows.json. On top of that, the existing CI step's cargo filter now also selects the smallint test, which only reads the committed file, so the step looks like it covers smallint when it does not. Details inline. - Nit: once #1266 merges, the README's "Types made producible since (
Smallint,SmallintEq)" will be incomplete. Inline.
Verified sound
- The drift check (
smallintWithoutCiphertexts) compares everything exceptc, includinghmand the key sets. It passes against a freshly built deterministic EQL guest, so the committed fixture matches today's build. - The Rust
FixtureandRowshapes match what Go writes. The query plaintext (-12) splits the rows, as the test asserts. tally.gokeepsProfileand the frozen v1 rows untouched. Its generatedtally_stash.gomatchesgo generate.
Checks run (no credentials)
- Built all five guests: base, deterministic, EQL, EQL deterministic, auth.
go generate ./...inlanguages/golang: no diff, nothing untracked.go vet ./encrypt/....go test -run 'TestV4Smallint|TestV4RowsMatch' ./encrypt: pass, not skipped.cargo test --locked -p eql-encryption-tests --test v4_types --test targets: 30 passed, 5 ignored.mise run test:encryption:postgresagainst a scratch local PostgreSQL 15: all 5 ignored PostgreSQL tests inv4_typespass, including the new one, and thetext_eqone passes too.git merge-treeagainst #1266's head.
| // TestV4RowsMatchTheCommittedFixture does for v4_rows.json: everything but | ||
| // each `c` must match, and the committed `c` values must open. The Rust | ||
| // suite opens the same rows and stores them in PostgreSQL, so a change to | ||
| // how the guest seals a smallint leaf shows there too. EQL_UPDATE_FIXTURES |
There was a problem hiding this comment.
This sentence, like the commit message's "a change to how the guest seals a smallint leaf shows in Rust and PostgreSQL", is true only for rows already in the committed file. See the comment on go_tally::fixture() in v4_types.rs: without a hand-off of today's rows, Rust and PostgreSQL see a guest change only after the file is regenerated.
There was a problem hiding this comment.
Fixed in 337e882. The doc comment no longer says a guest change shows in Rust and PostgreSQL. It now says EQL_UPDATE_FIXTURES leaves the committed file alone when only c moves, and that EQL_V4_SMALLINT_ROWS_OUT writes today's rows for CI to hand to Rust (EQL_V4_SMALLINT_ROWS). The commit message is reworded the same way. A guest change that moves only a smallint ciphertext reaches Rust's 16-bit open through the hand-off. PostgreSQL stores and queries the committed rows only.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
cipherstash-agent
left a comment
cipherstash-agent
left a comment
There was a problem hiding this comment.
Review attestation
Source: automated /code-review medium + /cross-check-review-findings pass by Claude Code on head 1838018. It read the full non-generated diff for eql-bindings, eql-codegen, the Go Tally model and its tests, the fixtures, and the changeset. I did not run the build or test suites. CI and the PR's reported local verification cover those.
Critical / blocking: none.
Findings: none survived cross-check.
Checked and found consistent:
i16is added to the sealedPlaintextset and mapped toInt16intargets.rs.encrypt_named,decrypt_namedandquery_namedeach gainSmallint/SmallintEqarms. TheSmallintord families stay non-producible with accurate reasons.plaintext_of,ENCRYPTION_DOMAINSand the regeneratedv4/targets.rsandeql_gen.goagree.- The date, timestamp and numeric gap text is updated in the codegen, the generated table and the tests.
- Range handling is covered on both bounds for every refusal path, and the
int32→SmallintEqequality term shares the integer one. - The changeset (
@cipherstash/eqlminor) is present. No skill underskills/names these types, so I flagged none.
Minor, non-blocking note: PR #1266 will conflict on ENCRYPTION_DOMAINS, the generated targets table and the catalog test lists, as the description already says. Whichever lands second should regenerate.
Generated by Claude Code
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1838018cb0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…o's rows in PostgreSQL A Tally test model, under Profile's table so its query shares v4_queries.json without touching Profile's frozen rows, holds an int16 Smallint, an int16 SmallintEq and an int32 SmallintEq. The rows seal to their EQL types and open back; an int32 outside the smallint range, above or below, is refused with ErrEncoding naming the field on the codec write, the single-field Encrypt and the Eq query; and Count.Eq derives the Rust fixture's query byte for byte. TestV4SmallintRowsMatchTheCommittedFixture checks v4_smallint_rows.json, which the Rust suite opens at 16 bits and inserts into eql_v4 columns, where = with the fixture's query finds the rows holding its value. The file is rewritten only when something other than `c` moves, so on its own it carries the ciphertexts of the last regeneration, not today's. EQL_V4_SMALLINT_ROWS_OUT and EQL_V4_SMALLINT_ROWS hand today's rows from Go to Rust, as EQL_V4_ROWS_OUT and EQL_V4_ROWS do for v4_rows.json, and the Go workflow's hand-off step now passes both pairs. So a guest change that moves only a smallint ciphertext, which Go's own round trip cannot see because the equality term is the same at every width, fails Rust's 16-bit open in the pull request that makes it. CI runs only the two open tests on the handed-off rows; PostgreSQL stores and queries the committed rows. The step's cargo filter is now --exact, so it names only the tests that read what it hands them.
1838018 to
337e882
Compare
coderdan
left a comment
coderdan
left a comment
There was a problem hiding this comment.
Incremental re-review of 1838018..337e882. Commit 1 (d5184c2) is unchanged, and the merge-base with next is still c612ed4. Only commit 2 moved.
Prior items (review)
- Low, no hand-off of today's smallint rows from Go to Rust, with a substring filter that only looked like it covered them: fixed. Go writes
EQL_V4_SMALLINT_ROWS_OUTbefore it compares with the committed file.go_tally::fixture()readsEQL_V4_SMALLINT_ROWSand falls back to the committed file. The CI step sets both pairs and now names its two tests with--exact. The CI log for this head (run 39187725154, job "WASI check, guests and Go (Linux)") showssmallint_rows_the_go_sdk_sealed_open_in_rust ... okandrows_the_go_sdk_sealed_open_in_rust ... ok, with2 passed; 17 filtered out. - Nit, the README list would leave out #1266's types: fixed. The README now says "Types made producible since are sealed into their own regenerable row fixtures (see the table above)". That stays true whichever PR merges second.
The Codex P1 on targets.rs:490 (the claim that eql-bindings depends on a published stack-encrypt 0.3.0 that lacks Int16): I agree with the author's reply. crates.io lists only stack-encrypt 0.1.0 and 0.2.0. The version = "0.3.0" requirement and ValueKind::Int16 both already exist on next, and this PR doesn't touch stack-encrypt or eql-bindings' Cargo.toml.
New findings (both small, both inline, both in the hand-off step)
- Low: if either test is later renamed, the
--exactfilter silently stops running it, and the step still passes. libtest exits 0 with1 passed; 18 filtered out. I checked this locally with one misspelled name. - Nit:
test -s "$rows" && test -s "$smallint_rows"doesn't stop the step when the first file is missing. The step still fails, but later and with a misleading message.
What I checked and found correct
-- --exact a b. libtest treats the two names as two filters ORed together, and with--exacteach one has to match a full test name. Both tests are top-level intests/v4_types.rs, so the names match. Locally the command ran exactly those two (2 passed; 17 filtered out), the same as CI.- The Go
-run '^(TestV4RowsMatchTheCommittedFixture|TestV4SmallintRowsMatchTheCommittedFixture)$'. It contains no/, so Go doesn't split it into subtest levels. With-vboth tests ran and passed, and both files were written. - Quoting. The regex is single-quoted, so the shell doesn't touch
(,|or$. Every variable is double-quoted. - The hand-off is real. I pointed
EQL_V4_SMALLINT_ROWSat a file that doesn't exist, and the smallint test failed with NotFound, so it reads the path the variable gives it. The file Go wrote today differs from the committed one only inc: it is byte-identical once eachcis removed, and it differs withcincluded. So Rust does open fresh ciphertexts. - Go writes the file before it compares. The write comes before the committed-file comparison and before
EQL_UPDATE_FIXTURES, and a failed write ist.Fatal. So CI gets today's rows even when the drift check then fails, and that failure still fails the step. This matchesTestV4RowsMatchTheCommittedFixture. - The override doesn't reach the PostgreSQL suite.
test-eql.ymlsets neither variable, sopostgres_stores_and_queries_smallint_rows_the_go_sdk_sealedkeeps using the committed rows, as the commit message says.frozen()still can't be redirected.
Checks run (no credentials)
- Built
wasm:guest:build:eql:deterministic. - Ran the Go half of the step with
-v: both tests passed, not skipped, and both files were non-empty. - Ran the Rust half exactly as written in the workflow, against those files: 2 passed.
- Ran it again with a missing
EQL_V4_SMALLINT_ROWSfile, and again with a misspelled exact name. Those runs give the two inline findings. cargo test --locked -p eql-encryption-testsinpackages/eql: all passed, 6 ignored.vitest run --config scripts/vitest.config.mjs: 75 of 77 files passed, including every workflow-scanning test (workflow-run-fail-fast,eql-suite-ci,crates-ci,workflow-working-directory, and so on). The two failures come from my environment: this worktree has nonode_modulesof its own, so it lacks@changesets/parseand the SQL bundle for@cipherstash/eql@3.0.4. Neither touches a file in this PR.gh pr checks 1267: all green.reviewwas skipped.
| smallint_rows="$RUNNER_TEMP/v4_smallint_rows.json" | ||
| (cd languages/golang && CGO_ENABLED=0 EQL_V4_ROWS_OUT="$rows" EQL_V4_SMALLINT_ROWS_OUT="$smallint_rows" go test -count=1 -run '^(TestV4RowsMatchTheCommittedFixture|TestV4SmallintRowsMatchTheCommittedFixture)$' ./encrypt) | ||
| test -s "$rows" && test -s "$smallint_rows" | ||
| EQL_V4_ROWS="$rows" EQL_V4_SMALLINT_ROWS="$smallint_rows" cargo test --locked --manifest-path packages/eql/Cargo.toml -p eql-encryption-tests --test v4_types -- --exact rows_the_go_sdk_sealed_open_in_rust smallint_rows_the_go_sdk_sealed_open_in_rust |
There was a problem hiding this comment.
Low: --exact makes this step stricter about which tests run, but it doesn't check that they ran. If either test is renamed (say smallint_rows_the_go_sdk_sealed_open_in_rust becomes ..._open_at_16_bits), libtest matches nothing for that name, runs the other test alone, and exits 0. I checked this locally with one name misspelled: 1 passed; 0 failed; 18 filtered out, cargo exit 0. The hand-off this PR adds would then be gone, and CI would stay green. The old substring filter had the same weakness, but --exact makes it break on any rename.
One way to make it fail loudly is to count before running:
filters=(--exact rows_the_go_sdk_sealed_open_in_rust smallint_rows_the_go_sdk_sealed_open_in_rust)
test "$(cargo test --locked --manifest-path packages/eql/Cargo.toml -p eql-encryption-tests --test v4_types -- "${filters[@]}" --list --format terse | grep -c ': test$')" -eq 2
EQL_V4_ROWS="$rows" EQL_V4_SMALLINT_ROWS="$smallint_rows" cargo test ... -- "${filters[@]}"A small test under scripts/__tests__/ that checks each name in this step against a fn in tests/v4_types.rs would also do it, and wouldn't touch the workflow.
| EQL_V4_ROWS="$rows" cargo test --locked --manifest-path packages/eql/Cargo.toml -p eql-encryption-tests --test v4_types rows_the_go_sdk_sealed_open_in_rust | ||
| smallint_rows="$RUNNER_TEMP/v4_smallint_rows.json" | ||
| (cd languages/golang && CGO_ENABLED=0 EQL_V4_ROWS_OUT="$rows" EQL_V4_SMALLINT_ROWS_OUT="$smallint_rows" go test -count=1 -run '^(TestV4RowsMatchTheCommittedFixture|TestV4SmallintRowsMatchTheCommittedFixture)$' ./encrypt) | ||
| test -s "$rows" && test -s "$smallint_rows" |
There was a problem hiding this comment.
Nit: this line only enforces its second half. shell: bash runs as bash -eo pipefail, and errexit ignores a failing command that isn't the last one in an && list. So if $rows is missing or empty, && stops before the second test, the list fails, and the step keeps going to cargo.
The realistic way to get there is the deterministic EQL guest not being built. deterministicEQLClient then calls t.Skip in both Go tests, go test prints ok, and neither file gets written. That case still fails loudly, but in the wrong place. cargo panics in both tests with fixtures/v4_rows.json is written by the Go SDK's TestV4RowsMatchTheCommittedFixture: ... NotFound (I reproduced the smallint version by pointing the variable at a path that doesn't exist). The message names the committed fixture, which is present, not the $RUNNER_TEMP file that is missing. That sends whoever reads the log to the wrong file.
Splitting it into two lines makes both checks stop the step:
test -s "$rows"
test -s "$smallint_rows"
2 participants
Summary
Go developers can now store a 16-bit integer in an EQL column, and search it by equality:
Smallint(stored and read only) andSmallintEq(=). EQL is the SQL library we install into a customer's PostgreSQL database to store and search encrypted values. Stack Encrypt is our Rust encryption engine, which the Go SDK runs as a WebAssembly guest. The engine and the Go SDK already had the 16-bit integer kind. The only thing missing was eql-bindings namingi16as the family's plaintext.This also fixes a stale message.
stashgen(the Go code generator) told users that the date, timestamp and numeric types wait for the engine to gain their kinds. The engine has them now. What those types actually wait for is a choice of Rust plaintext type, and the message now says that.Based on
next; independent of the other open EQL v4 PRs.Changes
eql-codegen and eql-bindings
("smallint", "")and("smallint", "eq")joinENCRYPTION_DOMAINS, andplaintext_ofmapssmallinttoint16/i16.i16joins the sealedPlaintextset of the by-name dispatch. It reads exactly anint16frame and refuses any other width.v4/{smallint,targets}.rsand Go'sencrypt/eql/eql_gen.go..changeset/eql-v4-smallint.md(@cipherstash/eqlminor), is kept separate from the sharedeql-v4-bindings.mdso this PR and feat(eql-bindings): produce the OPE-ordered EQL v4 types #1266 don't conflict.Tests (
packages/eql/tests/encryption)SmallintEq(42)has the same equality term asIntegerEq(42)under one column. That's ADR-0002's one integer equality domain.i32ciphertext that fits opens as ani16, and one that doesn't fit is refused.postgres_stores_and_finds_smallint_rows):=oneql_v4_smallint_eqfinds exactly the expected rows, includingi16::MINandi16::MAX;=;v4_queries.jsongains aSmallintEqquery (keytally).Go
A
Tallytest model coversint16→Smallint,int16→SmallintEqandint32→SmallintEq:int32outside the range, above or below, is refused withErrEncodingnaming the field. That holds on the codec write, the single-fieldEncryptand theEqquery;Count.Eqmatches the Rust fixture byte for byte.TestV4SmallintRowsMatchTheCommittedFixturewritesv4_smallint_rows.json. Rust opens those Go-sealed rows at 16 bits, and a PostgreSQL test stores them and checks=with the fixture's query.Tallyis a model of its own becauseProfile's rows are frozen instored_v4_rows_v1.json, and a newProfilefield would change them.The guest's and the SDK's catalog tests list the two new types;
SmallintEqanswerseq.Updated the README,
doc.go, the stashgen README and the CHANGELOG.Verification
packages/eql:mise run build,test:codegen,test:crates,test:encryption(420 passed),types:check(on the commit) andcodegen:parityall passed.mise run test:encryption:postgrespassed against a disposable PostgreSQL 17.5 (initdbcluster) with the v4 bundle built from the tree: all 6 tests, including the two new smallint ones.-D warningsoneql-bindings,eql-codegenandeql-encryption-tests(all features, all targets) was clean, and so was eql-bindings rustdoc with-D warnings.mise run wasm:guest:testpassed.languages/golang:mise run go:testpassed,go vet ./...was clean andmise run go:lintreported 0 issues.go generate ./...leaves no diff.Related
Refs #1130: the smallint storage and equality types.
Review notes
encryption/targets.rsand two entries inbindings.rs. The rest is generated or tests.SmallintOrdandSmallintOrdOpefollow once this PR and feat(stack-encrypt)!: derive every order term over its ADR-0002 order key, and order floats #1242 (order terms over ADR-0002's order keys) are both in, the way feat(eql-bindings): produce the OPE-ordered EQL v4 types #1266 does for the other number families.chronoandrust_decimalfeatures would giveNaiveDate,DateTime<Utc>andDecimal. But none of those implementsZeroize, which the dispatch requires of the plaintext copy it holds.ENCRYPTION_DOMAINS, the generated targets table and the same catalog test lists. Whichever lands second regenerates and merges those lists.