[coverage] Conformance findings: RESULTFETCH-020 #517

Summary

Surfaced by the multi-language coverage fan-out while conformance-testing these SPEC-IDs against databricks/databricks-sql-go. Each finding is committed as an expected-failure (xfail) test in the coverage PR — the test asserts the CORRECT (post-fix) behavior and stays red until THIS driver (databricks/databricks-sql-go) is fixed, then flips green as a tripwire.

Findings

• RESULTFETCH-020 [sea]: SEA/kernel backend panics with arrow: duplicate field with name "a" (arrow.StructOf via cdata.ImportCArrowSchema in kernel.newKernelRows) for any result with two identically named columns, including a single-row single-chunk SELECT 1 AS a, 2 AS a; the server returns both columns, so the failure is client-side Arrow schema assembly
  • failing test: TestDuplicateColumnNamesSurviveResultFetch (see the coverage PR diff under tests/)
• RESULTFETCH-020: SEA/kernel backend panics with arrow: duplicate field with name "a" (arrow.StructOf via cdata.ImportCArrowSchema in kernel.newKernelRows) for any result containing two identically named columns, including a single-row single-chunk SELECT 1 AS a, 2 AS a; the server returns both columns correctly, so the failure is client-side Arrow schema assembly

Reproduce & Expected

RESULTFETCH-020 — A query whose result set contains two columns with the SAME name is valid SQL (e.g.

Reproduce:

• Execute a one-row query with two identically named columns and read the
  result fully, through every fetch surface the driver exposes (row-oriented
  fetch-all / fetch-one, and the native Arrow/columnar accessor if present).
• Execute a duplicate-named query whose result is large enough to arrive in
  more than one chunk/batch, and read every row. Exercises concatenation of
  multiple equal-schema chunks. Chunk/batch COUNT is server- and driver-
  dependent and is deliberately NOT asserted -- only that all rows and both
  columns survive. ORDER BY id makes the first data row deterministic so the
  two columns can be told apart positionally (0 vs 1000000).
• Execute a JOIN whose two sides share a column name, so the duplication comes
  from SELECT * rather than from explicit aliasing.

Expected (per the shared spec):

• completes without an exception
• result has exactly 1 row(s)
• result has 2 column(s)
• col 0 is named a
• col 1 is named a
• col 0, row 0 == 1 (type Int32)
• col 1, row 0 == 2 (type Int32)
• completes without an exception
• result has exactly 200000 row(s)
• result has 2 column(s)
• col 0 is named a
• col 1 is named a
• col 0, row 0 == 0 (type Int64)
• col 1, row 0 == 1000000 (type Int64)
• completes without an exception
• result has exactly 1 row(s)
• result has 2 column(s)
• col 0 is named id
• col 1 is named id
• col 0, row 0 == 1 (type Int32)
• col 1, row 0 == 1 (type Int32)

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: Queries returning duplicate column names fail with ArrowInvalid: Can't unify schema with duplicate field names since 4.2.6 (#989) databricks-sql-python#995 — which seeded the shared language-neutral spec. This issue tracks the same conformance gap in databricks/databricks-sql-go; the reference PR is for cross-referencing the intended behavior, NOT a change to this repo.
• Coverage PR carrying the reproducing xfail test(s): https://github.com/databricks/databricks-driver-test/pull/1884