Problem
GetColumns (and list_columns) on the Thrift path throws NotSupportedException when a table contains a GEOMETRY or GEOGRAPHY column, because the SQL type-name parser has no entry for these types and no catch-all.
Call path:
SparkConnection.SetPrecisionScaleAndTypeName is invoked per column during GetColumns; the default arm (csharp/hiveserver2/csharp/src/AdbcDrivers.HiveServer2/Spark/SparkConnection.cs:113-120) calls SqlTypeNameParser<…>.Parse(typeName, colType).SqlTypeNameParser.Parse throws NotSupportedException($"Unsupported SQL type name: '{input}'") when no registered parser matches (.../Hive2/SqlTypeNameParser.cs:119-122).- The registered parser set (
SqlTypeNameParser.cs:54-101) has no GEOMETRY/GEOGRAPHY entry, and the only "simple" parser matches an exact literal base name (^\s*<name>\s*$) with no catch-all. A repo-wide grep for GEOMETRY|GEOGRAPHY finds zero handling in the driver.
Result: metadata discovery crashes outright on any table with a geospatial column.
Note on related work
This is distinct from the GeoArrow data-path work (#339, #340, #361, PR #350), which converts geometry values to geoarrow.wkb. Those do not touch the SqlTypeNameParser metadata path — a table with a geometry column still throws in GetColumns regardless.
Comparator reference: D11 in the ADBC SEA Public Preview plan ("Thrift's list_columns can't parse GEOMETRY (and GEOGRAPHY) types; throws on wildcard column patterns"). The wildcard-column-pattern throw noted in D11 should be verified as part of this issue too.
Expected
GetColumns/list_columns should return a row for GEOMETRY/GEOGRAPHY columns (mapping to a reasonable ADBC/Arrow type) rather than throwing.
Problem
GetColumns(andlist_columns) on the Thrift path throwsNotSupportedExceptionwhen a table contains aGEOMETRYorGEOGRAPHYcolumn, because the SQL type-name parser has no entry for these types and no catch-all.Call path:
SparkConnection.SetPrecisionScaleAndTypeNameis invoked per column duringGetColumns; thedefaultarm (csharp/hiveserver2/csharp/src/AdbcDrivers.HiveServer2/Spark/SparkConnection.cs:113-120) callsSqlTypeNameParser<…>.Parse(typeName, colType).SqlTypeNameParser.ParsethrowsNotSupportedException($"Unsupported SQL type name: '{input}'")when no registered parser matches (.../Hive2/SqlTypeNameParser.cs:119-122).SqlTypeNameParser.cs:54-101) has noGEOMETRY/GEOGRAPHYentry, and the only "simple" parser matches an exact literal base name (^\s*<name>\s*$) with no catch-all. A repo-wide grep forGEOMETRY|GEOGRAPHYfinds zero handling in the driver.Result: metadata discovery crashes outright on any table with a geospatial column.
Note on related work
This is distinct from the GeoArrow data-path work (#339, #340, #361, PR #350), which converts geometry values to
geoarrow.wkb. Those do not touch theSqlTypeNameParsermetadata path — a table with a geometry column still throws inGetColumnsregardless.Comparator reference: D11 in the ADBC SEA Public Preview plan ("Thrift's list_columns can't parse GEOMETRY (and GEOGRAPHY) types; throws on wildcard column patterns"). The wildcard-column-pattern throw noted in D11 should be verified as part of this issue too.
Expected
GetColumns/list_columnsshould return a row for GEOMETRY/GEOGRAPHY columns (mapping to a reasonable ADBC/Arrow type) rather than throwing.