Looking through both

• docs(extensions): describe the decimal precision and scale rule #1223
• fix(extensions)!: correct decimal division return precision #1274

has surfaced a number of issues related to decimal arithmetic handling.

SQL Specification

My initial assumption had been that we had been encoding the SQL specification rules for scale and precision derivation into the Substrait specification. However the specification only defines rules for computing scale for addition, substraction and multiplication. Everything else is implementation defined.

See 6.12 in SQL:1992

Source of Truth

Given that the specification leaves so much to implementations, the natural question is what rules are actually encoding. From poking around, it looks like we're broadly cribbing from:

• SQL Server
• Calcite
• Hive/Spark

These are not the only rules floating around for this, but it appears to be what we are using today. The SQL Server rules are what we adhere to most closely.

Questions

This raises two immediate questions for me:

1. Is the SQL Server implemenation of this the one that we want to bake into the specification?
2. Is there even a "neutral" definition we could bake into the spec for this, given the even the SQL specification doesn't declare a "standard" here?

From poking around, there are so many different ways of computing output precision and scale that it feels like no one definition we could pick that would actually work for interop across a broad swathe of systems. Which leads to a bigger question / idea:

Instead of trying to define one or more rules for deriving these, should we switch to a model where a producer can request a desired precision / scale (based on its preferred computation schema) and then a consumer can accept or request the plan based on whether it can satisfy the precision / scala with loss of accuracy?