4

The error is

*** Exception: Incompatible {errSQLType = "int8", errHaskellType = "Int", errMessage = "types incompatible"}

It looks like any value returned by count(*) in the query must be converted into Integer rather than Int. If I change those specific variables to type Integer, the queries work.

But this error wasn't being raised on another machine with the same exact code. The first machine was 32 bit and this other one 64-bit. That's the only difference I could discern.

Does anyone have any insight into what is going on?

Chris Stryczynski
  • 30,145
  • 48
  • 175
  • 286
dan
  • 43,914
  • 47
  • 153
  • 254
  • have you tried using `Int32` or something? – DiegoNolan Jun 07 '13 at 19:46
  • I haven't tried Int32, but I think that may work just as well as Integer. I just have not seen this integer type conversion wrinkle documented anywhere. – dan Jun 08 '13 at 20:14

2 Answers2

2

The PostgreSQL count() functions returns a Bigint type, see

http://www.postgresql.org/docs/9.2/static/functions-aggregate.html

Bigint are 8 bytes see http://www.postgresql.org/docs/9.2/static/datatype-numeric.html

Haskell int is ~ 2**29 which implies it a 4 byte integer.

http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Int.html

Then its normal that PostgreSQL or its API will not do an implicit downwards conversion in precision.

So use a Haskell int64 type or cast count(*) to integer.

Tim Child
  • 2,994
  • 1
  • 26
  • 25
1

As documented in the FromField module, postgresql-simple will only do client-side conversions between numerical types when there isn't any possibility of overflow or loss of precision. Note especially the list of types in the haddocks for the instance FromField Int: "int2, int4, and if compiled as 64-bit code, int8 as well. This library was compiled as 32-bit code." The latter part of that comment is of course specific to the build that hackage itself performs.

On 32-bit platforms, Int is a 32-bit integer, and on 64-bit platforms, Int is a 64-bit integer. If you use Int32 you'll get the same exception. You can use Int64 or the arbitrary-precision Integer type to avoid this problem on both kinds of platform.

lpsmith
  • 707
  • 3
  • 8