lpsmith / postgresql-simple

Mid-level client library for accessing PostgreSQL from Haskell
Other
206 stars 71 forks source link

Better error messages? #201

Open saurabhnanda opened 7 years ago

saurabhnanda commented 7 years ago

Redirecting my rant from https://github.com/tomjaguarpaw/haskell-opaleye/issues/260


I got the following runtime errors. What is the best way to debug these?

Copy-pasting the generated SQL in psql command-line generates a more helpful error message, pointing out the exact line + character, along with the column alias. Can this not be made available in the Haskell error?

*** Exception: SqlError {sqlState = "42703", sqlExecStatus = FatalError, sqlErrorMsg = "column \"name\" does not exist", sqlErrorDetail = "", sqlErrorHint = ""}

*** Exception: Incompatible {errSQLType = "timestamp", errSQLTableOid = Just (Oid 78669), errSQLField = "result4_3", errHaskellType = "UTCTime", errMessage = ""}

*** Exception: UnexpectedNull {errSQLType = "varchar", errSQLTableOid = Just (Oid 78725), errSQLField = "result2_3", errHaskellType = "Text", errMessage = ""}
lpsmith commented 7 years ago

Well, the latter two errors won't be errors in psql. Rather they are conversion errors inside postgresql-simple; as far as the backend is concerned, there is no error.

As for the second error, the types are incompatible. In postgres, timestamp (without time zone) is a local time with an offset from UTC that cannot be known without further context, which corresponds to the time package's LocalTime. Whereas timestamptz (with time zone) is an unambiguous point in time in and of itself, without the need for further context; thus it can be converted to UTCTime and ZonedTime. You may want to read the documentation in postgresql-simple's Time module.

As for the third error, the backend is returning null, but there is no way to represent null in Haskell's Text type. So you could use Maybe Text instead, or tweak your sql and/or schema to ensure that the backend will never return null.

As for the first error, your request might be reasonable, assuming the backend reports the information and psql doesn't somehow figure it out itself. Somebody would have to figure out how to obtain that information via libpq, and then we could modify postgresql-simple and/or postgresql-libpq to obtain that information.

saurabhnanda commented 6 years ago

Following up from the comment on LinkedIn. Fixing this issue might need some internal code reorganisation. Are you open to such changes?