fix(postgresql): type a DateTime parameter from its Kind, not its CLR type (weasel#403)

[jeremydmiller]

Closes #403. Narrows #404.

The bug

cmd.AddNamedParameter("n", DateTime.UtcNow);
await cmd.ExecuteScalarAsync();

ArgumentException: Cannot write DateTime with Kind=UTC to PostgreSQL type
'timestamp without time zone', consider using 'timestamp with time zone'.

Verified against a live Postgres. It only ever surfaced at execution time, so a unit assertion on the stamped type would not have caught the original report.

Cause

With no explicit type, Weasel typed the parameter from the value's CLR type, and PostgresqlProvider maps typeof(DateTime) to Timestamp unconditionally. But Postgres' choice depends on the value — Npgsql resolves Kind=Utc to timestamptz, Kind=Local/Unspecified to timestamp. A per-type mapping cannot express that.

DateTime[] and List<DateTime> failed identically through the array branch.

Change

New IDatabaseProvider<,,>.ToParameterTypeForValue(object), defaulting to today's ToParameterType(value.GetType()) — so no other provider changes behaviour. It is a default interface method plus a public virtual on DatabaseProvider<,,>, so external implementers are unaffected. PostgresqlProvider overrides it to read DateTime.Kind, for scalars and for IReadOnlyList<DateTime> (covers arrays and List<T>; Npgsql forbids mixing Kinds in one array, so the first element decides).

Three call sites were typing per-CLR-type and now route through it:

site	note
DatabaseProvider.AddNamedParameter	the reported one
CommandBuilderBase.AppendParameter	same bug, reached via the interface
CommandExtensions.With(cmd, name, DateTime)	hard-coded NpgsqlDbType.Timestamp, so .With(name, DateTime.UtcNow) always threw

The second and third were found while fixing the first; each would have left the bug reachable.

Column types are deliberately untouched

A column has one type, so DDL stays per-type — GetDatabaseType(typeof(DateTime)) still returns timestamp without time zone, now pinned by a test. Only parameters follow their value.

Verification

Live Postgres, every case previously throwing:

value	before	after
DateTime.UtcNow	✗ throws	TimestampTz ✓
DateTime[] all Utc	✗ throws	Array | TimestampTz ✓
List<DateTime> all Utc	✗ throws	Array | TimestampTz ✓
DateTime.Now	Timestamp ✓	Timestamp ✓
DateTime[] empty	Array | Timestamp ✓	unchanged ✓
string / Guid / int / DateTimeOffset / string[]	✓	unchanged ✓

Includes an integration test that actually writes and reads back a UTC DateTime, since the unit-level assertion alone would not have caught this.

Suites: Postgres 798 passed on all four matrix legs (net9.0/net10.0 × case-sensitive true/false), Core 21, SQLite 361. MSSQL / Oracle / MySQL covered by CI — unchanged by the default implementation.

On #404

This removes the observable AddParameter / AddNamedParameter divergence for DateTime: both now yield TimestampTz for a UTC value, one by deferring to Npgsql and one by resolving per value. What remains of #404 is narrower — AddNamedParameter still throws for types with no mapping where AddParameter succeeds. Left open deliberately; it is an API-direction call, not a bug fix.

🤖 Generated with Claude Code