[coverage] Conformance findings: DATATYPE-042

Start with sql.ColumnType.DatabaseTypeName() and the failing TestGeospatialTypeNamePreservesSRID shown in the coverage PR under tests/. Compare the intended behavior with the reference databricks-odbc PR 417, then verify the result-set metadata and catalog TYPE_NAME values for GEOMETRY(0) and GEOGRAPHY(4326) on both thrift and SEA backends.

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

• DATATYPE-042 [thrift]: sql.ColumnType.DatabaseTypeName() reports a GEOMETRY(0)/GEOGRAPHY(4326) column as "STRING" — the spatial type keyword and its declared SRID are both dropped (cf. PECOBLR-4121)
  • failing test: TestGeospatialTypeNamePreservesSRID (see the coverage PR diff under tests/)
• DATATYPE-042 [sea]: sql.ColumnType.DatabaseTypeName() reports a GEOMETRY(0)/GEOGRAPHY(4326) column as "STRING" on the kernel/SEA backend too — the spatial type keyword and its declared SRID are both dropped (cf. PECOBLR-4121)
  • failing test: TestGeospatialTypeNamePreservesSRID (see the coverage PR diff under tests/)
• DATATYPE-042: sql.ColumnType.DatabaseTypeName() reports a GEOMETRY(0)/GEOGRAPHY(4326) column as "STRING" on both thrift and sea — the spatial type keyword and its declared SRID are both dropped, so a consumer reading the type name cannot tell the column is geospatial or which coordinate system it uses (cf. PECOBLR-4121)

Reproduce & Expected

DATATYPE-042 — Verify that the type NAME a driver reports for a GEOMETRY / GEOGRAPHY column carries the column's spatial reference identifier (SRID) exactly as the server reports it -- "GEOMETRY(0)" / "GEOGRAPHY(43…

Reproduce:

• Read the type name reported for geom_col / geog_col from the RESULT-SET metadata of
  this SELECT, then call the driver's get-columns catalog API for the same table and
  read the TYPE_NAME cell of the same two columns.

Expected (per the shared spec):

• completes without an exception
• full assertion contract:

result:
- no_exception: true
- result_metadata_type_name:
    column: geom_col
    equals: GEOMETRY(0)
- result_metadata_type_name:
    column: geog_col
    equals: GEOGRAPHY(4326)
- catalog_column_type_name:
    column: geom_col
    equals: GEOMETRY(0)
- catalog_column_type_name:
    column: geog_col
    equals: GEOGRAPHY(4326)

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-odbc/pull/417 — 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/1598