GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — [coverage] Conformance findings: PARAMQUERY-022 · Issue #887 · databricks/databricks-sql-python

[coverage] Conformance findings: PARAMQUERY-022 #887

New issue
Copy link
New issue
Copy link
Closed as duplicate
Closed as duplicate
[coverage] Conformance findings: PARAMQUERY-022#887
Copy link

Description

@peco-engineer-bot
peco-engineer-bot
bot
opened on Aug 3, 2026
Issue body actions

Summary

Surfaced by the multi-language coverage fan-out while conformance-testing these SPEC-IDs against databricks/databricks-sql-python. 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-python) is fixed, then flips green as a tripwire.

Findings

  • PARAMQUERY-022 [thrift]: DecimalParameter._cast_expr formats the DECIMAL cast with its arguments transposed — CAST_EXPR.format(self.scale, self.precision) — so a declared precision=10/scale=2 target emits DECIMAL(2,10) (scale greater than precision, invalid) instead of DECIMAL(10,2), losing the declared decimal shape on the wire
    • failing test: test_decimal_target_carries_declared_precision_and_scale (see the coverage PR diff under tests/)

Reproduce & Expected

PARAMQUERY-022 — Verify a DECIMAL/NUMERIC target with a declared precision and scale sends the parameter as a DECIMAL carrying THAT precision/scale, so the bare-marker result column is a decimal of the declared shape and the fractional digits survive.

Reproduce:

SELECT ? AS v

Expected (per the shared spec):

  • result has exactly 1 row(s)
  • col 0, row 0 == '123.45' (type Decimal128)
  • full assertion contract:
result:
- row_count: 1
- column:
    index: 0
    row: 0
    type: Decimal128
    equals: '123.45'
- result_column_type_matches_target: true

Context

  • The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-odbc/pull/167 — which seeded the shared language-neutral spec. This issue tracks the same conformance gap in databricks/databricks-sql-python; 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/1061

Activity

  1. vuanhphung commented on Oct 30, 2026

    @vuanhphung
    vuanhphung
    on Oct 30, 2026
    Collaborator
    More actions

    Closing as a duplicate of #901, which tracks the same DecimalParameter precision/scale swap (precision=10, scale=2 is sent as DECIMAL(2,10) and rejected by the server) and is the issue the fix PRs reference. This still reproduces on 4.8.0.

  2. vuanhphung
    closed this as a duplicateof [coverage] Conformance findings: PARAMQUERY-021 #901 on Oct 30, 2026
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

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.