SP
fix: use from_str_via_hash for generic scalar strings
spaceandtimefdn/sxt-proof-of-sql#1144

/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.

Please go through the following checklist

Rationale for this change

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.

What changes are included in this PR?

  • Add Scalar::from_str_via_hash(&str) with a default implementation backed by the existing byte-slice hash helper.
  • Remove the generic string From bounds from Scalar.
  • Route generic VarChar string-to-scalar conversions through from_str_via_hash in database, commitment, proof, and Arrow conversion paths.
  • Add a regression test that checks from_str_via_hash("abc") matches the existing byte-hash path.

Are these changes tested?

Yes.

I ran the following locally:

  • cargo fmt --check
  • cargo check -p proof-of-sql --no-default-features
  • cargo 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).

Claim

Total prize pool $100
Total paid $0
Status Pending
Submitted March 16, 2026
Last updated March 16, 2026

Contributors

JA

javery556

@javery556

100%

Sponsors

SP

Space and Time

@spaceandtimelabs

$100