/claim #228
Please be sure to look over the pull request guidelines here: https://github.com/spaceandtimelabs/sxt-proof-of-sql/blob/main/CONTRIBUTING.md#submit-pr.
! is used if and only if at least one breaking change has been introduced.source scripts/run_ci_checks.sh.source scripts/check_commits.sh, and the commit history is certified to follow clean commit guidelines as described here: https://github.com/spaceandtimelabs/sxt-proof-of-sql/blob/main/COMMIT_GUIDELINES.mdmain have been incorporated to this PR by simple rebase if possible, if not, then conflicts are resolved appropriately.This PR addresses checklist item 2 from #228 only.
The issue asks to remove the generic string conversion bounds from Scalar and replace them with an explicit from_str_via_hash(&str) path. This keeps string hashing behavior explicit at the trait level instead of relying on blanket From<&str> / From<String> bounds.
Scalar::from_str_via_hash(&str) with a default implementation backed by the existing byte-slice hash helper.From bounds from Scalar.VarChar string-to-scalar conversions through from_str_via_hash in database, commitment, proof, and Arrow conversion paths.from_str_via_hash("abc") matches the existing byte-hash path.Yes.
I ran the following locally:
cargo fmt --checkcargo check -p proof-of-sql --no-default-featurescargo check -p proof-of-sql --no-default-features --features="std"cargo check -p proof-of-sql --no-default-features --features="test"cargo check -p proof-of-sql --no-default-features --features="arrow"cargo check -p proof-of-sql --no-default-features --features="rayon"cargo check -p proof-of-sql --all-targets --no-default-features --features="test"cargo check -p proof-of-sql --all-targets --no-default-features --features="arrow"cargo check -p proof-of-sql --all-targets --no-default-features --features="rayon"cargo test -p proof-of-sql we_can_get_scalar_from_hashed_strings --no-default-features --features="test"cargo test -p proof-of-sql mixed_data_types --no-default-features --features="arrow test"Note: source scripts/run_ci_checks.sh currently does not execute cleanly in this checkout because it extracts literal run: prefixes from the workflow YAML. I ran it, then ran the relevant cargo checks above directly. Default/perf feature lanes are also not fully runnable on this host because the dependency stack includes Linux-only / x86_64-only paths (blitzar-sys, halo2curves asm).
javery556
@javery556
Space and Time
@spaceandtimelabs