This is great news if you are coding accounting/banking software and good to see the IBM standards referenced. Given that decimal32 starts to see gaps in the continuous dollars.cents range at about $100,000 I don’t expect that has many real world applications (except legacy compatibility).
For general applications, I prefer to use Rational representation for decimals (Rat or FatRat) and Allomorphs (RatStr, FatRatStr) to maintain a literal representation like this https://raku.land/zef:librasteve/FatRatStr.
I don't get it. You had to face the problem of a type in a network protocol that had no direct Java equivalent, and decided, for something so low level and performance critical, to create a new instantiable Class? With the expressed intent to not use it for mathematical operations?
So instead of suffering the penalties of
bytes -> BigDecimal (with validation of course)
you thought it's better to add more construction steps in the form of
bytes -> Decimal32 (validation included) -> Big Decimal?
Do you know what kind of performance overhead this entails for your JDBC driver? Because the latter looks roughly about twice as slow, depending on the complexity of your validation code.
Nice to see Firebird still being actively developed.
I'd also like to draw attention to the parent project Firebird. For some reason (probably its ties to Borland/Delphi?) it never became widely popular, even though it combines SQLite's ease of use with a proper fully featured database engine.
For example, it supports proper ALTER TABLE which doesn't force you to recreate tables and copy data around when you go beyond the most trivial use cases.
This is pretty much the only discussion I've found on this site:
https://news.ycombinator.com/item?id=22155260