Warum generiert Dapper unterschiedliche SQL mit / ohne Mini-Profiler-Verbindung?

Dapper (1.13 Noobget-Paket) erstellt unterschiedliche SQL-Anweisungen, je nachdem, ob es mit einer einfachen ADO.NET-Datenbankverbindung oder mit einer dekorierten Mini-Profiler-Datenbankverbindung verwendet wird.

Beispielcode (getestet mit Postgresql)

Using:

using System.Linq;
using Dapper;
using Npgsql;
using NUnit.Framework;
using StackExchange.Profiling;
using StackExchange.Profiling.Data;

Test1 verwendet eine einfache ADO.NET-Verbindung und schlägt fehl :

[TestFixture]
public class DapperTests {
  private const string cnnstr = "HOST=...;DATABASE=...;USER ID=...;PASSWORD=...;";

  [Test]
  public void Test1() {
    using (var cnn = new NpgsqlConnection(cnnstr)) {
      cnn.Open();

      // The following line fails:
      cnn.Query<int>("SELECT 1 WHERE 42 IN @Items", new {Items = new[] {41, 42, 43}}).Single();

      // Npgsql.NpgsqlException : ERROR: 42883: operator does not exist: integer = integer[]
    }
  }

Test2 verwendet eine Mini-Profiler-Verbindung, die um die ADO.NET-Verbindung gewickelt wird und erfolgreich ist :

  [Test]
  public void Test2() {
    using (var cnn = new NpgsqlConnection(cnnstr))
    using (var profiled = new ProfiledDbConnection(cnn, MiniProfiler.Start())) {
      profiled.Open();

      int result = profiled.Query<int>("SELECT 1 WHERE 42 IN @Items", new {Items = new[] {41, 42, 43}}).Single();

      Assert.AreEqual(1, result);
    }
  }
}

Mit Blick auf das generierte SQL wird klar, warum Test1 fehlschlägt:

• SQL von Test1: SELECT 1 WO 42 IN ( (array [41,42,43]) :: int4 [] )
• SQL von Test2: SELECT 1 WO 42 IN (((41)), ((42)), ((43)))

Arrays unterstützen kein IN.

Warum generiert Dapper verschiedene SQL, wenn es mit / ohne eine profilierte Verbindung verwendet wird?

Warum generiert es ein Array [...] mit einer einfachen Verbindung? Aufgrund der Dokumente von dapper sollte es ein Tupel generieren: