Hi Andrei, One argument for standardizing the strings rather than forbidding non-finite values: Java has been writing "NaN", "Infinity" and "-Infinity" for a long time, so that metadata already exists. Forbidding leaves it permanently unreadable; standardizing plus a Java reader fix makes it readable.
The divergence I'd worry about most is the silent one — rust, PyIceberg and cpp writing null. A refused write is a bug report; a default that quietly becomes null is a wrong value found much later. +1 on fixtures in iceberg-verification. Raghav On Thu, Oct 22, 2026 at 8:48 AM Andrei Tserakhau via dev < [email protected]> wrote: > Hi all, > > The spec allows NaN, Infinity and -Infinity as float and double values > [1], and doesn't restrict them as defaults [2]. But JSON single-value > serialization says float and double are a "JSON number" [3], and JSON > numbers can't be NaN or Infinity (RFC 8259, section 6). The same applies to > the REST spec, where FloatTypeValue and DoubleTypeValue are type: number > [4]. So there is no valid way to write, for example, initial-default = > +Infinity. > > Today each client works around this differently: > > - Java writes the strings "NaN", "Infinity" and "-Infinity". This comes > from Jackson's default, not from an explicit choice [5]. Java's own reader > then rejects these strings [6], so Java can't read back what it writes. > - iceberg-rust, PyIceberg and iceberg-cpp write null, so the value is > silently lost. > - iceberg-go refuses to write them. > > Two questions: > > 1. Should the spec define how non-finite float and double values are > serialized in JSON? I think it has to, so clients stop diverging. > > 2. If so, should we standardize what Java already writes, i.e. the exact, > case-sensitive strings "NaN", "Infinity" and "-Infinity", with finite > values staying JSON numbers? That would mean updating Appendix D and the > two OpenAPI value types. Java would only need a reader fix, and the other > clients would align. The alternative is to say non-finite values must not > be written to JSON, in which case writers error, Java included. > > Whichever we pick, I'd like it written down in the spec or as conformance > fixtures in iceberg-verification [7], so clients can check against it > instead of against each other. > > Thanks, > Andrei > > [1] > https://github.com/apache/iceberg/blob/60897e0b828580cc20e591424179d9b5c574e8d6/format/spec.md?plain=1#L281-L282 > [2] > https://github.com/apache/iceberg/blob/60897e0b828580cc20e591424179d9b5c574e8d6/format/spec.md?plain=1#L367-L374 > [3] > https://github.com/apache/iceberg/blob/60897e0b828580cc20e591424179d9b5c574e8d6/format/spec.md?plain=1#L2085-L2095 > [4] > https://github.com/apache/iceberg/blob/60897e0b828580cc20e591424179d9b5c574e8d6/open-api/rest-catalog-open-api.yaml#L5391-L5399 > [5] > https://github.com/apache/iceberg/blob/60897e0b828580cc20e591424179d9b5c574e8d6/core/src/main/java/org/apache/iceberg/SingleValueParser.java#L277-L286 > [6] > https://github.com/apache/iceberg/blob/60897e0b828580cc20e591424179d9b5c574e8d6/core/src/main/java/org/apache/iceberg/SingleValueParser.java#L73-L79 > [7] https://github.com/apache/iceberg-verification > > -- Thanks Raghav
