Add ODBC-native row-wise array fetch for fast bulk retrieval

[christianparpart]

Customers on high-latency links wait the longest when retrieving many rows because each row is its own SQLFetch round-trip — fetching 1000 rows costs 1000 round-trips. This adds the read-side counterpart of the existing CreateAll/UpdateAll batch-write path: Query<Record>().All()/Range() (and two-record JOIN tuples) now bind result columns row-wise directly into the caller's std::vector<Record> storage and pull whole row blocks per SQLFetchScroll, collapsing the round-trips from N to ~ceil(N/depth). Values land in place (zero-copy); results are byte-identical to the per-row path.

The fast path is transparent and gated — a record qualifies when every result column is row-bindable (the same SqlRowBindableColumn set the write side uses: primitives, date/time/datetime, numeric, char fixed-capacity strings, and non-numeric optionals of those) and the driver supports row-array fetching. Anything else (growable strings/binary, GUID, variant) transparently falls back to the unchanged per-row path. Verified against SQLite, SQL Server 2022 and PostgreSQL.

Changes

• SqlStatement::FetchAllRowWise — new low-level primitive mirroring ExecuteBatchNativeRowWise: sets SQL_ATTR_ROW_BIND_TYPE = sizeof(Record) + SQL_ATTR_ROW_ARRAY_SIZE, grows-and-rebinds the destination per block, clamps depth to a memory budget, and restores single-row statement state via a Finally guard on every exit (including exceptions). Nullable columns use an over-allocated row-strided NULL indicator; optionals are pre-engaged and reset on NULL. Char fixed strings bind SQL_C_CHAR inline with a per-row length/trim fixup.
• SqlConnection::SupportsNativeRowArrayFetch and RoundTripsNarrowTextByteExact — driver capability checks kept on the connection. The latter carves out PostgreSQL (whose psqlODBC transcodes SQL_C_CHAR through the client codepage), so records carrying a fixed-capacity string fall back to the per-row wide path there rather than risk mangling non-ASCII bytes.
• DataMapper retrieval wiring — compile-time eligibility (CanRowWiseFetchRecord/CanRowWiseFetchTuple plus the narrow-text carve-out) and the ReadResults branch for both single-record and two-record tuple result sets.
• RowWiseFetchTests — covers fixed/nullable/temporal/fixed-string columns, NULL/empty/full-capacity values, multi-block boundaries, empty results, Where/Range, statement reuse and the std::string fallback, asserting via a block-fetch-counting logger that the fast path actually ran (and that fixed-string records fall back on PostgreSQL). A hidden opt-in benchmark ([.rowwisefetchbench]) reproduces the comparison below.

Performance

The structural win is round-trip count: for 200k rows the row-wise path issues ~196 SQLFetchScroll calls instead of 200,000 SQLFetch calls (~1000x fewer round-trips). Measured end-to-end (release build, median of 5 reps, Query<>().All() vs the per-row fallback, both materializing the same std::vector<Record>):

Backend	Transport	per-row SQLFetch	row-wise block fetch	speedup
SQLite	in-process	643 ms / 500k	541 ms	1.19x
PostgreSQL	localhost TCP	167 ms / 200k	109 ms	1.53x
SQL Server 2022	localhost TCP	134 ms / 200k	67 ms	2.01x

The speedup scales with per-round-trip transport cost. In-process SQLite has no socket, so its ~1.2x is purely reduced per-call CPU/ODBC overhead — the floor, and a latency-independent constant. Over a localhost socket (sub-millisecond RTT) it is already 1.5-2x.

On a high-latency link the round-trip term dominates: wall-clock ≈ round-trips × RTT, so the per-row path pays ~N × RTT while the block path pays ~ceil(N/depth) × RTT, and the speedup approaches the effective array depth (up to ~1000x for narrow records, less for wide rows that clamp to a smaller depth, and divided by whatever the driver already prefetches per fetch). For example, modelled at 50 ms RTT for 100k rows: ~83 min (per-row) vs ~5 s (block). The local numbers above are a conservative lower bound demonstrating the mechanism; the round-trip-count reduction is what carries the win to the WAN case.

[Yaraslaut]

Thanks a lot for the improvement