Skip to content

fix(query): define lossless SQL result encodings for DuckDB 2 types #279

Description

@vishr

The whole-PR review of #272 identified low-severity SQL result serialization gaps outside its five inline findings: #272 (review) .

At e818a8d, ExecuteSQL converts binary VARIANT attributes to DuckDB-escaped strings rather than the previous base64 representation. Its generic []byte conversion also returns UUID, BLOB and DuckDB 2 GEOMETRY as raw strings; the pinned Go binding cannot decode TIME_NS. The latter raw-byte handling predates this PR, while the engine upgrade adds more exposed result types. Canonical Parquet attributes remain typed; this issue concerns the client boundary.

Implement a documented result encoding contract with explicit type information where needed. Preserve binary bytes, format UUIDs canonically, choose a deliberate GEOMETRY representation, and preserve all nine fractional digits for TIME_NS. Keep native timestamp predicates intact and keep AST validation, DESCRIBE and projection on the same connection and pinned snapshot. Do not introduce a legacy result path or a second engine.

Acceptance: tests through a real NewDuck/ExecuteSQL cover scalar and nested binary values, a literal string that resembles DuckDB's byte escape syntax, NULLs, UUIDs, GEOMETRY and TIME_NS. JSON round trips must preserve the chosen contract and nanosecond precision. Existing SQL restrictions and supported nested numeric values must continue to pass.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions