[coverage] Conformance findings: RESULTFETCH-020

Open
  • Is something wrong?
#517 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
49/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
go
Domain
database, databases

Research direction

Start with the failing TestDuplicateColumnNamesSurviveResultFetch in the coverage PR and trace the SEA/kernel path through kernel.newKernelRows and cdata.ImportCArrowSchema, where duplicate fields trigger the panic. Reproduce with the single-row query, then check row-oriented and Arrow fetches plus multi-chunk and JOIN cases. Done means duplicate column names and both positional values survive every fetch surface without an exception.

Written by the indexing model from the issue text.

Description

engineer-bot

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

Dominant language
Go
Stars
54
Forks
71
Avg merge
16h 3m
Merged PRs (30d)
21

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from databricks/databricks-sql-go

All issues in databricks/databricks-sql-go

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.