Passing `Double`s to `val_` sometimes leads to runtime errors

[LightAndLight]

Minimal example:

query ::
  (BeamSqlBackend be, BeamSqlBackendCanSerialize be Int32, BeamSqlBackendCanSerialize be Double) =>
  Q be db s (QExpr be s Int32, QExpr be s Double)
query = pure (val_ 99, val_ 1.0)

...

_ <- runSelectReturningList $ select query

Running this query throws an exception:

BeamRowReadError {brreColumn = Just 1, brreError = ColumnTypeMismatch {ctmHaskellType = "Double", ctmSQLType = "numeric", ctmMessage = "types incompatible"}}

The generated SQL is SELECT 99 AS "res0", 1.0 AS "res1".

Using as_ doesn't helpl, i.e. as_ @Double (val_ 1.0).

The workaround is to use cast_ in a pretty redundant way: cast_ (val_ (1.0 :: Double)) Database.Beam.Query.DataTypes.double. That compiles to the following SQL: SELECT 99 AS "res0", CAST((1.0) AS DOUBLE PRECISION) AS "res1".

I'm surprised that the integer value isn't affected by the same issue.

---

beam-core version: 0.10.1.0
beam-postgres version: 0.5.3.1

[LaurentRDC]

Hmmm this is an interesting conundrum.

In Postgres, the literal 1.0 is of type NUMERIC.

The Postgres NUMERIC type is an exact representation of numbers with arbitrary precision. It would be lossy to convert a Postgres NUMERIC to a Haskell Double.

This is why, in postgresql-simple (on which beam-postgres is built), there is no conversion from Postgres NUMERIC to Haskell Double. You should instead use Haskell Scientific.

All this means is that the error message of "types incompatible" is correct.

[LaurentRDC]

One option to prevent this in the future is to prevent the ability for val_ (1.0 :: Double) to exist, which would imply that SqlValable Double should not exist specifically for the Postgres backend.

[LaurentRDC]

I think the solution above would be a breaking change. Instead, I will try to make the error message more explicit about what's going on.

[LightAndLight]

One option to prevent this in the future is to prevent the ability for val_ (1.0 :: Double) to exist, which would imply that SqlValable Double should not exist specifically for the Postgres backend.

I don't think it's a good idea to rule out SqlValable for Double. Rather, val_ (1.0 :: Double) should compile to 1.0::double precision.

[LaurentRDC]

Yes that's a better idea. Although the problem of Postgres-specificity remains in think? I've never seen it this notation before

[LaurentRDC]

Turns out there WAS a Postgres-specific way to add the ::double precision annotation. I've added a test case as well to ensure this issue doesn't crop up again.

Thank you for your report and fix suggestion!

[LaurentRDC]

This issue is fixed in the new release of beam-postgres-0.5.4.1