Adding INT128 support as JDBC type NUMERIC

[Mark Rotteveel]

Firebird 4 will introduce INT128 (a 128-bit integer). JDBC doesn't
provide a suitable type for this (the closest would be BIGINT, but that
is a bit problematic in my opinion). So, for reasons of compatibility, I
want to add support in Jaybird as a JDBC type NUMERIC. See also
https://github.com/FirebirdSQL/jaybird/blob/master/devdoc/jdp/jdp-2020-08-int128-support.md
for details.

This would allow it to work. By default as a java.math.BigDecimal, but
mapping to java.math.BigInteger would also work.

Let me know your thoughts on this.

Mark
--
Mark Rotteveel

[Arioch The]

is there some standard de facto library of infinite precision numbers and math in JVM ecosystem?

вс, 28 июн. 2020 г., 13:20 Mark Rotteveel <ma...@lawinegevaar.nl>:

--
You received this message because you are subscribed to the Google Groups "firebird-java" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-jav...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebird-java/f8516577-baa0-9c83-82af-4ee72503cc2a%40lawinegevaar.nl.

[Mark Rotteveel]

On 28-06-2020 15:11, Arioch The wrote:
> is there some standard de facto library of infinite precision numbers
> and math in JVM ecosystem?

I describe the options in jdp-2020-08. Java provides
java.math.BigDecimal (which is the standard type for JDBC types NUMERIC
and DECIMAL), and it provides java.math.BigInteger.

However, JDBC doesn't really associate a JDBC type with BigInteger. In
some (but not all) of the mappings defined in appendix B of the JDBC
specification, it is associated with JDBC type BIGINT, but as the
standard type associated with JDBC type BIGINT is a (64-bit) long, using
that as a type would be problematic. In my experience, a lot of the
libraries and tools written in Java work with the assumption that JDBC
type BIGINT means 64-bit long. Using that for a 128-bit integer would
then yield overflow errors when the value is out of range, or
potentially problems if you'd let getObject return a
java.math.BigInteger instead of a java.lang.Long.

Jaybird already supports getting and setting java.math.BigInteger on
NUMERIC and DECIMAL, so if you want to use it, you can. Furthermore a
java.math.BigDecimal is basically a wrapper around a
java.math.BigInteger with a scale.

The advantage of using JDBC type NUMERIC (or DECIMAL) is that through
its mapping with java.math.BigDecimal, most tools will transparently be
able to work with it. There might potentially be some edge-cases when
generating DDL or casts in SQL (ie tools might generate - for example -
NUMERIC(38) or NUMERIC(38,0) instead of INT128). In those same cases,
those tools would likely generate BIGINT when mapped to JDBC type
BIGINT, which would be worse, because at least NUMERIC(38) and INT128
cover the same range of values and the same can't be said for BIGINT.

When using a custom type, or Types.OTHER, it is hard to say what will
happen, but I suspect it would be worse.

Mark
--
Mark Rotteveel