Recognize native GEOMETRY column in geospatial datasets

[AmrMortada]

The problem

When Duckle reads any geospatial input, column with the GEOMETRY type are detected as string instead of geometry.

Starting with DuckDB 1.5, GEOMETRY is a built-in core data type rather than an extension-specific type. Duckle should recognize it as a native geometry column instead of falling back to string.

Proposed solution

Add support for DuckDB's native GEOMETRY type in Duckle's type detection.

When a column is of type GEOMETRY, Duckle should:

• Detect it as geometry instead of string.
• Display it alongside the other supported data types.
• Preserve the geometry type throughout the pipeline so spatial workflows can use it directly.

This would align Duckle with DuckDB's native type system and improve the experience when working with spatial datasets.

Alternatives / workarounds

Additional context

DuckDB 1.5 moved GEOMETRY into the core database engine, allowing extensions to produce and consume geometry values natively without depending on the Spatial extension.

Blog post:
https://duckdb.org/2026/03/09/announcing-duckdb-150#geometry-rework

It would be great if geometry were recognized as a native type as well.

[SouravRoy-ETL]

Implemented on main (4bbd478), shipping in the next release.

GEOMETRY is now a first-class type end to end: engine type detection maps DuckDB's geometry / geometry('epsg:4326') to a native geometry type instead of falling through to string, it is added to the shared type enum and the schema-panel type list, and a column declared geometry casts to native GEOMETRY (not VARCHAR) so it is preserved through the pipeline.

Verified: a GeoJSON -> Parquet run keeps the column as geometry('epsg:4326') rather than string. Thanks for the DuckDB 1.5 context. Leaving open until release.