fix(c/driver): support binding dictionary-encoded columns of any plainly-supported value type

[fornwall]

DISCLAIMER: This PR was mostly AI generated. I have reviewed and is ready to take on follow up work to change or investigate things.

Context: While looking at adding a test for bound dictionary encoded parameters in the python validation suite (adbc-drivers/validation#256), I encountered this issue.

Summary

Binding a dictionary-encoded column as a query parameter was under-supported in the C SQLite and PostgreSQL drivers. Dictionary encoding is an encoding of the same logical values, not a distinct logical type, so a driver that can bind a plain column of type T should accept dictionary<values=T> and decode it. pandas produces these routinely — pd.Series([1, 2, 1], dtype="category") is a dictionary<values=int64, indices=int8>.

Both drivers had the same pattern: a whitelist of supported dictionary value types plus a special-cased dictionary writer that re-implemented value binding. In both cases the fix takes the delegate-to-the-plain-path approach — resolve the index, then dispatch on the value type through the code the plain column already uses. The missing types then come for free, by construction, rather than by growing a second whitelist that can drift from the first.

One commit per driver, plus a follow-up commit applying review findings (allocation-free type bookkeeping in the SQLite binder, NUMERIC-target and CREATE TABLE affinity fixes, test-helper dedup). The branch also carries an unrelated CI commit letting the nightly clippy step fail without blocking (the 2026-07-15 nightly ICEs on this workspace).

1. SQLite (statement_reader.c)

The whitelist and the bind implementation had already drifted, which is exactly the bug this restructuring prevents:

• binary / large_binary / fixed_size_binary / binary_view were whitelisted as supported, but the dictionary case called sqlite3_bind_text unconditionally, regardless of value type. Binary-valued dictionaries landed in SQLite with text affinity and read back as strings instead of blobs.
• int64 / double dictionaries were rejected with NOT_IMPLEMENTED, though the plain types bind fine.

Bulk ingest now also declares dictionary-encoded columns with their value type's affinity in CREATE TABLE: previously such a column got no declared type at all (BLOB affinity), so e.g. a dictionary-encoded int column compared differently against string literals than the same column ingested plain.

2. PostgreSQL (copy/writer.h, bind_stream.h)

The COPY writer supported dictionaries only for binary/string/large_binary/large_string; everything else fell through to "not implemented". PostgresType::FromSchema already resolves a dictionary to its value type when picking the parameter OID, so no type-mapping change was needed.

Dictionary resolution happens at the top of MakeCopyFieldWriter, before the NUMERIC/JSONB target-type dispatch, so ingesting a dictionary-encoded integer/decimal column into an existing NUMERIC column delegates to the same target-type-aware writer the plain column gets.

While adding the end-to-end bind test I found a pre-existing latent bug that also affects the already-supported string/binary dictionaries: an index that is itself non-null but points at a null value within the dictionary was written as an inline -1 field length. That is correct for COPY, but the extended query protocol signals a null parameter via a null param_values entry, so PostgreSQL saw a zero-length value and rejected it:

ERROR: insufficient data left in message
CONTEXT: unnamed portal parameter $2   (SQLSTATE 08P01)

Dictionary nulls are now resolved in BindAndExecuteCurrentRow.

Changes in support

value type	sqlite — current	sqlite — new	postgres — current	postgres — new
string	✅	✅	✅	✅
large_string	✅	✅	✅	✅
string_view	✅	✅	❌	✅
binary	❌ 1	✅	✅	✅
large_binary	❌ 1	✅	✅	✅
fixed_size_binary	❌ 1	✅	❌	✅
binary_view	❌ 1	✅	❌	✅
bool	❌	✅	❌	✅
int8 / int16 / int32 / int64	❌	✅	❌	✅
uint8 / uint16 / uint32 / uint64	❌	✅	❌	✅
half_float / float / double	❌	✅	❌	✅
date32	❌	✅	❌	✅
timestamp	❌	✅	❌	✅
time64	— 2	—	❌	✅
decimal128 / decimal256	— 2	—	❌	✅
interval_month_day_nano	— 2	—	❌	✅
duration	— 2	—	❌	✅

Possible follow-up: cache converted dictionary values

Delegating to the plain path means a value is converted once per row, not once per distinct dictionary value — so for conversion-heavy types the repetition that dictionary encoding exists to exploit is currently thrown away. A per-column cache keyed by dictionary index would convert once per distinct value instead. This is left out for now.

Applicable to exactly the types whose plain writer does real per-value work:

driver	value types	per-value work today
sqlite	date32, timestamp	ArrowDate32ToIsoString / ArrowTimestampToIsoString: malloc + format + strlen + SQLITE_TRANSIENT copy + free, per row
postgres	decimal128, decimal256	stringify into raw_decimal_string, re-parse into digit groups, allocate a std::vector<int16_t>, per row

Every other type is already effectively free per value and would gain nothing: the sqlite string/binary paths hand SQLite a pointer into the dictionary buffer with SQLITE_STATIC (zero copy), the int/float paths are a single read, and the postgres timestamp/interval/ duration/binary writers are plain arithmetic plus a memcpy with no allocation.

What it would save: O(k) conversions instead of O(n), for k distinct values over n rows. Since dictionaries are used precisely when k << n, the saving scales with the compression ratio. It would not save the bind/write itself — SQLite binds per row and PostgreSQL COPY writes bytes per row regardless — so the ceiling is the conversion and allocation only.

Footnotes

1. Worse than unsupported: these were accepted by the whitelist and then bound with sqlite3_bind_text, so the write succeeded silently and the data was stored as TEXT. Non-UTF-8 binary (most binary) became unreadable — typeof() returned text, length() counted malformed UTF-8 characters rather than bytes, and reading the value back raised a decode error. ↩ ↩² ↩³ ↩⁴

2. Not supported as a plain column by this driver, so there is no plain path to delegate to and no dictionary support is added. These are unchanged. ↩ ↩² ↩³ ↩⁴