…olumns

Row/SimpleQueryRow validated the requested index against the RowDescription
column count but indexed the ranges vector built from the DataRow field count,
which the server controls independently. A DataRow with fewer fields than
advertised columns made get/try_get (and a plain 0..row.len() loop) panic with
an out-of-bounds index. Validate the two counts match when the row is built so
the mismatch surfaces as a recoverable error instead.

The time 0.2 FromSql impls for Date/PrimitiveDateTime/OffsetDateTime added the
server-supplied value to the 2000-01-01 epoch with the plain + operator, which
panics when the result falls outside time's representable year range
(-100_000..=100_000). A server-sent (or merely far-future) DATE/TIMESTAMP could
therefore crash the client. time 0.2 has no checked_add, so validate the
resulting Julian day against the representable range first, mirroring the
checked_add the time 0.3 impls already use.

The PBKDF2 iteration count in the SCRAM server-first message is server-controlled
and was passed to hi() unbounded, so a malicious or impersonating server could
send i=4294967295 and force the client to run billions of HMAC-SHA256 operations
inline on the connect path before authentication completes. Reject any iteration
count above 100_000 before computing the salted password — ~24x the PostgreSQL
default of 4096, matching the cap pgjdbc adopted for CVE-2026-42198.

The generated FromSql for a composite struct assigned each field from an
Option populated by matching server-reported field names, then unwrapped them.
A server reporting a duplicate field name (accepted by accepts(), which only
checks every reported name matches some field) leaves another field unset, so
the unwrap panicked. Use ok_or(..)? so a malformed composite returns a decode
error rather than crashing the caller.