bsql-driver-postgres 0.27.0

PostgreSQL wire protocol driver for bsql — binary protocol, arena allocation, zero-copy
Documentation
[package]
name = "bsql-driver-postgres"
version.workspace = true
edition.workspace = true
rust-version.workspace = true
license.workspace = true
repository.workspace = true
readme = "../../README.md"
description = "PostgreSQL wire protocol driver for bsql — binary protocol, arena allocation, zero-copy"

[features]
default = []
# TLS via rustls. The `ring` crypto provider is hard-pinned on both
# `rustls` and `tokio-rustls`: all `ClientConfig`s in bsql are built
# through `tls_common::build_client_config`, which passes the provider
# explicitly via `builder_with_provider` and never touches rustls's
# process-level auto-selection. Pinning the feature here guarantees the
# `rustls::crypto::ring` module is always in scope when the `tls`
# feature is on, even if a downstream user disables workspace defaults.
tls = [
    "dep:rustls",
    "rustls/ring",
    "dep:webpki-roots",
    "dep:tokio-rustls",
    "tokio-rustls/ring",
    "dep:rustls-pemfile",
]
async = ["dep:tokio"]
detect-n-plus-one = ["dep:log"]
time = ["dep:time"]
chrono = ["dep:chrono"]
uuid = ["dep:uuid"]
decimal = ["dep:rust_decimal"]

# Dev-only feature enabling the feature-unification regression test in
# tls_common. When on, it brings in rustls with `aws-lc-rs` alongside
# bsql's `ring`, simulating the exact cargo feature unification scenario
# that would panic a naive `ClientConfig::builder()`. The test asserts
# bsql's code path survives and the legacy builder panics — proof that
# the repro is real and the fix is not a false-green.
feature-unification-repro = []

[dependencies]
bsql-arena = { workspace = true }
rapidhash = { workspace = true }
simdutf8 = { version = "0.1", default-features = false, features = ["std"] }
smallvec = { workspace = true }

# TCP keepalive (FIX 25)
socket2 = { version = "0.5", default-features = false }
# Password zeroization (FIX 32) — already a transitive dep via crypto crates
zeroize = { version = "1", default-features = false }

# Auth
sha2 = { version = "0.10", default-features = false }
hmac = { version = "0.12", default-features = false }
pbkdf2 = { version = "0.12", default-features = false, features = ["hmac"] }
base64 = { version = "0.22", default-features = false, features = ["alloc"] }
md-5 = { version = "0.10", default-features = false }
rand = { version = "0.9", default-features = false, features = ["std", "os_rng"] }

# TLS (optional)
rustls = { workspace = true, optional = true }
webpki-roots = { workspace = true, optional = true }
tokio-rustls = { workspace = true, optional = true }
rustls-pemfile = { workspace = true, optional = true }

# Async runtime (optional)
tokio = { workspace = true, features = ["rt", "net", "io-util", "sync"], optional = true }

# N+1 detection (optional)
log = { workspace = true, optional = true }

# Feature-gated type support (optional)
time = { workspace = true, optional = true }
chrono = { workspace = true, optional = true }
uuid = { workspace = true, optional = true }
rust_decimal = { workspace = true, optional = true }

[dev-dependencies]
proptest = "1"
tokio = { workspace = true, features = ["rt-multi-thread", "macros"] }
rcgen = { workspace = true }
# Activate the aws-lc-rs crypto provider for the feature-unification
# regression test. At runtime, cargo's feature unification sees both
# `ring` (from bsql's `tls` feature) and `aws-lc-rs` (from this dev-dep)
# enabled on `rustls`, which is exactly the scenario that panics the
# legacy `ClientConfig::builder()`.
rustls = { workspace = true, features = ["aws-lc-rs"] }