+dev adding the dev mailing list, maybe somebody there can answer the reasoning.
when comparing sql server with Oracle and Postgress: https://docs.microsoft.com/en-us/sql/t-sql/data-types/decimal-and-numeric-transact-sql?view=sql-server-ver15 <https://docs.microsoft.com/en-us/sql/t-sql/data-types/decimal-and-numeric-transact-sql?view=sql-server-ver15> https://docs.oracle.com/cd/A84870_01/doc/server.816/a76965/c10datyp.htm#743 <https://docs.oracle.com/cd/A84870_01/doc/server.816/a76965/c10datyp.htm#743> https://www.postgresql.org/docs/9.1/datatype-numeric.html <https://www.postgresql.org/docs/9.1/datatype-numeric.html> One allows for negative scale, the other doesn’t. My biggest issue with the current decimal spec is that it does not encode the scale (uses the scale defined in the schema), as such it cannot accommodate a Oracle and Postgres NUMBER without scale coercion. there are other differences (like NAN, …) But there is no reason why the decimal2 logical type should not be created to address the above… or even better promote decimal to a first class type...https://issues.apache.org/jira/browse/AVRO-2164 <https://issues.apache.org/jira/browse/AVRO-2164> —Z > On Mar 2, 2020, at 2:34 PM, Christopher Egerton <chr...@confluent.io> wrote: > > Hi all, > > I've been trying to do some research on the logical decimal type and why the > scale of a decimal type must be between zero and the precision of the type, > inclusive. The ticket https://issues.apache.org/jira/browse/AVRO-1402 > <https://issues.apache.org/jira/browse/AVRO-1402> has a lot of discussion > around the design of the type, but I haven't been able to find any rationale > for the limitations on the scale of the type. > > These don't appear to align with existing conventions for precision and scale > in the context of SQL numeric types, the JDBC API, and the Java standard > library's BigDecimal class. In these contexts, the precision must be a > positive number, but the scale can be any value--positive (representing the > number of digits of precision that are available after the decimal point), > negative (representing the number of trailing zeroes at the end of the number > before an implicit decimal point), or zero. It is not bounded by the > precision of the type. > > The definitions for scale and precision appear to align across these > contexts, including the Avro spec, so I'm curious as to why the Avro > spec--seemingly an anomaly--is the only one to declare these limitations on > what the scale of a decimal type can be. > > Does anyone know why these exist, and if not, would it be okay to file a > ticket to remove them from the spec and begin work on it? > > Cheers, > > Chris
