Skip to content

Report DECIMAL precision and scale through database/sql - #513

Open
ajaykr0905 wants to merge 1 commit into
databricks:mainfrom
ajaykr0905:fix/decimal-metadata-500
Open

ajaykr0905 wants to merge 1 commit into
databricks:mainfrom
ajaykr0905:fix/decimal-metadata-500

Conversation

@ajaykr0905

Copy link
Copy Markdown

Summary

 database/sql metadata
 ├── Thrift rows
+│   └── read DECIMAL precision/scale qualifiers
 └── kernel rows
+    └── preserve Arrow Decimal128 precision/scale

Implement driver.RowsColumnTypePrecisionScale for both result backends so sql.ColumnType.DecimalSize() reports declared DECIMAL qualifiers. Non-decimal columns, invalid indexes, and incomplete Thrift qualifiers continue to return ok=false.

Closes #500.

Evidence

  • Before: both rows implementations omitted RowsColumnTypePrecisionScale, so DECIMAL metadata returned ok=false.
  • After: focused Thrift and Arrow metadata regressions pass 10/10; the affected packages pass with the race detector; all 1,231 default unit tests pass (2 credential-gated E2E tests skipped); the complete databricks_kernel-tagged suite passes; lint reports 0 issues; Linux and Darwin builds pass.

No live Databricks warehouse call was made. Tests exercise the same Thrift qualifier and Arrow Decimal128 metadata consumed by the two rows implementations.

Merge Danger

Door: Two-way

Blast Radius: Result metadata

The change only adds an optional database/sql/driver metadata interface. Scanned DECIMAL values and non-decimal metadata behavior are unchanged.

Assisted-by: OpenAI Codex
Signed-off-by: Ajay Kumar <206070437+ajaykr0905@users.noreply.github.com>

This branch has not been deployed

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[coverage] Conformance findings: DATATYPE-043

1 participant