v2.0.13

Fixed

• Parameterized DDL/DML issued via ExecuteQuery (Python
  cursor.execute(sql, params)) could be silently lost. Execution routing
  skipped statements with bound parameters, so a parameterized
  DELETE/UPDATE/INSERT took GizmoSQL's lazy query path and only ran when
  the caller read the result — and, since 2.0.9, moving on to the next
  statement before the write finished sent a server-side cancel that
  interrupted it (server log: INTERRUPT Error: Interrupted!). Reported as a
  DuckLake/UUID quirk (DELETE ... WHERE uuid_col = ? no-oping while the
  literal form worked) — the literal form was simply already on the DoPut
  path. Bound DDL/DML now routes through the prepared-statement update RPC
  (executing once per bound row, like executemany), and bound
  ... RETURNING statements are materialized. Covered by
  TestIntegrationBoundDMLPersistsWithoutFetch,
  TestIntegrationBoundReturningPersistsWithoutFetch and the Python
  TestBoundParameterRouting tests.

v2.0.12

Fixed

• Closing a statement while ExecuteUpdate is blocked now cancels the
  update on the server. The statement tracks its in-flight blocking
  execute call (ExecuteUpdate, and ExecuteQuery until it returns a
  reader); Close — and CancelQuery — issue CancelFlightInfo for it
  exactly once, so a language binding that releases the statement handle
  to cancel (the Node.js adbc-driver-manager has no cancel API) no
  longer leaves a DoPut update such as CREATE TABLE ... AS running to
  completion. Previously only abandoned streaming results and blocked
  queries were interrupted. Covered by unit tests and
  TestIntegrationCloseWhileUpdateExecutingCancelsOnServer.

v2.0.11

Changed

• Bump google.golang.org/grpc 1.83.1 -> 1.83.2, matching the upstream
  Flight SQL ADBC driver's 1.12.2 registry release
  (https://adbc-drivers.org/blog/2026/09/02/updated-flightsql-driver/).
  The 1.83.2 fix hardens gRPC servers (requests missing both
  :authority and Host are rejected); this driver is a gRPC client only
  and govulncheck reports no reachable vulnerability, so this is parity,
  not a fix. No functional changes.

v2.0.10

Added

• Python: dbapi.connect() accepts catalog= and db_schema= keyword
  arguments to make a catalog/schema current for the session at connect
  time. They are shorthand for the standard ADBC
  adbc.connection.catalog / adbc.connection.db_schema connection
  options (which already worked via conn_kwargs), sent to the server
  via Flight SQL SetSessionOptions. Unit and live-server tests added.

Fixed

• Parameter binding without an explicit Prepare. Bind/BindStream
  on a SQL query now auto-prepare the statement. The upstream Flight SQL
  driver treats an unprepared Bind as staged bulk-ingest data and then
  fails ExecuteQuery/ExecuteUpdate with
  must set IngestTargetTable before bulk ingestion, so consumers whose
  statement API has no prepare step — notably the Node.js
  @apache-arrow/adbc-driver-manager, where connection.query(sql, params) is setSqlQuery + bind + executeQuery — could not bind
  parameters at all. An explicit Prepare still works and is not
  repeated; bulk ingest (adbc.ingest.target_table) and Substrait plans
  are unchanged; SetSqlQuery/SetSubstraitPlan reset the prepared
  state so a re-bound statement re-prepares against the new query.
  Live-server tests added. Note that correct handling of NULL,
  dictionary-encoded and multi-row bound parameters also needs GizmoSQL
  server >= 1.38.1, which fixed the server-side parameter conversion.

Changed

• README: document the 16 MiB gRPC message cap on bulk ingest and how to
  tune it (adbc.flight.sql.client_option.with_max_msg_size, or smaller
  source batches).

v2.0.9

Added

• Server-side query cancellation. The driver now sends the Flight
  CancelFlightInfo action to GizmoSQL — the same call the gizmosql-jdbc
  driver makes — so an abandoned query is interrupted on the server instead
  of running to completion (or until the server's --query-timeout).
  Previously "cancel" only tore down the local gRPC stream, which the server
  ignored. Cancellation now happens on:
  • AdbcStatementCancel / AdbcConnectionCancel — which the Python
    adbc_driver_manager invokes from its SIGINT handler, so Ctrl+C or a
    Jupyter kernel interrupt during a long query now cancels it, as does an
    explicit cursor.adbc_cancel().
  • Closing a statement, or releasing a result stream, before it is drained
    (cursor.close(), del cursor, connection close, normal interpreter
    shutdown) while the query is still executing.
  • Go: connections and statements implement gizmosql.QueryCanceler
    (CancelQuery(ctx)), safe to call from another goroutine while
    ExecuteQuery/ExecuteUpdate is blocked.
    The cancel is issued over the session's existing gRPC connection (so TLS,
    mTLS and auth settings need no re-derivation) and is best-effort: a query
    that already finished is a harmless no-op. A hard kill of the client
    process (kill -9, OOM) still cannot notify the server; that case needs a
    server-side fix (tracked in the gizmosql repo).

Changed

• The driver's log filter now also suppresses the ERROR-level "endpoint
  stream ended with error ... INTERRUPT Error: Interrupted!" line that
  upstream emits when a cancelled query's stream ends; the interrupt still
  surfaces to the caller as the statement's error.

v2.0.8

Fixed

• Geometry-aware ingest works against GizmoSQL ≥ 1.37.0. GizmoSQL 1.37.0
  honours geoarrow.* extension metadata server-side and creates GEOMETRY
  columns directly during bulk ingest. The driver's 2.0.1 interim-table path
  then failed in every ingest mode with
  Binder Error: No function matches 'st_geomfromwkb(GEOMETRY)', because it
  unconditionally re-typed the interim columns with ST_GeomFromWKB. The
  driver now inspects the interim table's column types and only converts
  columns that actually landed as BLOB (older servers), so the same code
  path works against both old and new servers without version sniffing.
  Users on GizmoSQL ≥ 1.37.0 must upgrade to this driver release for
  geometry ingest; non-geometry ingest was never affected.

v2.0.7

Changed

• Bumped Go dependencies: google.golang.org/grpc 1.83.0 -> 1.83.1,
  google.golang.org/protobuf 1.36.11 -> 1.36.12, OpenTelemetry 1.44.0 ->
  1.45.0, golang.org/x/* and genproto to current, plus other indirect
  modules. Flight SQL (arrow-adbc/go/adbc v1.12.0, arrow-go v18.7.0)
  was already at the latest release.
• Raised the Go toolchain to 1.26.7 (go directive in go.mod, which CI
  reads via go-version-file) so driver binaries pick up the Go CVE fixes
  shipped in 1.26.6+ — matching the upstream ADBC Flight SQL 1.12.1 rebuild.

v2.0.6

Fixed

• Client-initiated stream cancellations are no longer logged as errors.
  When an ADBC consumer closes a DoGet stream early — as DuckDB's
  adbc_scanner and Columnar's adbc extension both do after probing a
  result's schema — the upstream Flight SQL driver's default logger
  emitted a spurious ERROR "FlightSQL endpoint DoGet failed ... context canceled" JSON record on stderr. The driver now installs a logger that
  suppresses expected context canceled errors (real errors are still
  logged).
• ADBC_DRIVER_FLIGHTSQL_LOG_LEVEL=warn now actually selects the WARN
  level (a switch fall-through bug left it at ERROR; warning was
  unaffected).
• The driver's database wrapper now forwards SetLogger, so the
  log-level environment variable handling in the C shared library (and
  any adbc.DatabaseLogging caller) works again instead of silently
  doing nothing.

Changed

• Bumped google.golang.org/grpc to 1.83.0. (Other direct dependencies —
  arrow-adbc 1.12.0, arrow-go 18.7.0 — are already current.)

v2.0.5

Changed

• Python dbapi: fetching after a successfully executed DDL/DML statement
  (cursor.execute("CREATE ...") then fetchall()) now returns an empty
  result (None/[]) instead of raising
  ProgrammingError: Cannot fetchall() before execute(), matching
  sqlite3/duckdb semantics. Generic DB-API consumers (e.g. sqlframe)
  fetch unconditionally after execute() and only then inspect
  cursor.description; the strict raising broke server-side
  spark.read.* schema inference in sqlframe-gizmosql. Fetching on a
  cursor that never executed still raises.

v2.0.4

Fixed

• packaging/gizmosql.toml.in: the windows_amd64 and windows_arm64
  shared-library paths pointed at adbc_driver_gizmosql.dll, but the
  release tarballs ship libadbc_driver_gizmosql.dll (verified against
  the v2.0.3 assets for both architectures). Manifest-based driver
  loading on Windows could not find the DLL as a result.