Why do we want to deviate from the IEEE 754 standard here? According to that (and also according to the Cloud Spanner backend) NaN == NaN should return false.

The following SQL statement for example returns false:

select (IEEE_DIVIDE(0.0, 0.0) = IEEE_DIVIDE(0.0, 0.0)) as b

That is a good point and I considered this.

The issue that we have is that on import / export in Apache Beam (see here) we compare mutations before committing. Since we allow for PGNumerics that allow for such a value, import / export is failing and that is why we are loosening the restriction here.

If you feel strong that we should not make changes here, we could try and explore a change in Apache Beam itself, but I guess we would just be re-implementing equality checks over there.

This is maybe a slightly hypothetical problem, but I don't think we should implement this in Value. However, it might make sense to implement it in Mutation (if doable). That is:

If someone executes the following query:

SELECT FloatValue1, FloatValue2
FROM SomeTable
WHERE FloatValue1 != FloatValue2

Then resultSet.getValue("FloatValue1).equals(resultSet.getValue("FloatValue2")) should return false for all rows.

On the other hand, for Mutations the difference between two NaN values is void, as they will both set the value of a row to the same. So:

      Mutation mutation1 = Mutation.newInsertBuilder("SomeTable")
          .set("FloatValue").to(Value.float64(Double.NaN))
          .build();
      Mutation mutation2 = Mutation.newInsertBuilder("SomeTable")
          .set("FloatValue").to(Value.float64(Double.NaN))
          .build();
      // The following could (should?) be true as both mutations will have the same effect.
      assertTrue(mutation1.equals(mutation2));

Would that solve the problem in Beam?

Yes, this would solve the problem for us. In addition, is it possible to see Double.NaN in PgNumeric Value?

In addition, is it possible to see Double.NaN in PgNumeric Value?

Yes, that is possible.

Changed the implementation to check for NaNs only in mutations

In addition, is it possible to see Double.NaN in PgNumeric Value?

Yes, that is possible.

Hi @thiagotnunes , is this case considered? I see we only try to cast the type to float64 but I am not an expert on client libraries. Ignore me if I am wrong.

Hey Michael, since this fix is on the public repository we don't have pg numeric here yet. I will make the necessary changes in the other repository as well.

oh, yes. Sorry, you are absolutely right.

No worries!

nit: maybe for future reference we should add a short comment on why we are doing this

Good point, added a comment here