Postgresql-simple has been progressing since my last announcement of version 0.1 nearly a year ago. Since then there has been many changes by myself and contributors, some of which will break your code with or without compilation errors. So this post will attempt to highlight some of the bigger changes. Probably the most exciting recent change is the new support for PostgreSQL’s array types, largely due to work from Jason Dusek, Bas van Dijk, and myself. Here’s two examples of a table and query that makes use of this functionality:
CREATE TABLE assocs ( id INT NOT NULL , link INT NOT NULL ); CREATE TABLE matrices ( id INT NOT NULL , matrix FLOAT8 );
import qualified Data.Vector as V import Database.PostgreSQL.Simple import Data.Int(Int64) getAssocs :: Connection -> IO [(Int,V.Vector Int)] getAssocs conn = do query_ conn "SELECT id, ARRAY_AGG(link) FROM assocs GROUP BY id" insertMatrix :: Connection -> Int -> V.Vector (V.Vector Double) -> IO Int64 insertMatrix conn id matrix = do execute conn "INSERT INTO matrices (id, matrix) VALUES (?,?)" (id, matrix)
In order to properly support the
FromField a => FromField (Vector a) instance, the
TypeInfo system was overhauled. Previously, the only information it tracked was a mapping of type OIDs to type names, first by consulting a static table and then using a per-connection cache, finally querying the
pg_type metatable. This was useful for writing
FromField instances for postgresql types that do not have a stable OID, such as those provided by an extension, like the period type from Temporal Postgres or the hstore type from the contributed modules bundled with PostgreSQL. However, proper array support required more information, especially the type of the array’s elements. This information is now available in an easily extended data structure, available in the new
Database.PostgreSQL.Simple.TypeInfo module. This was introduced in 0.3, 0.3.1 added support for range and composite types; however there is not yet any
FromField instance that makes use of this information or deals with these types.
IO at Conversion Time
Version 0.3 also stopped pre-computing the type name of every column and storing these in a vector before converting the results, by allowing a restricted set of IO actions at conversion time. This is a win, because the common case is that the typename is never consulted; for example almost all of the out-of-box
FromField instances examine the type OID alone. Also, since IO information no longer has to be computed before conversion takes place, it makes it practical to consider using IO information that would rarely be used in normal circumstances, such as turning table OIDs into table names when errors are encountered. It’s possible to extend the IO actions available to
FromRow instances by accessing the data constructor of the
Conversion monad via the
This required changing the type of the
FromField.typename operator, which will break your FromField instances that use it. It also required small changes to the
FromRow interface, which has a chance of breaking some of your FromField and FromRow instances if they don’t strictly use the abstract Applicative and/or Monad interfaces. However, all of this breakage should be obvious; if your code compiles, it should work with the new interface.
Version 0.3.1 also introduced out-of-box support for hstore. The hstore type provides key-value maps from textual strings to textual strings. Conversions to/from lists and
Data.Map is provided, while conversions from other Haskell types can be easily implemented via the
HStoreBuilder interface (similar to my own json-builder package), and conversions to other Haskell types can easily be implemented via the conversion to lists.
CREATE TABLE hstore_example ( id INT NOT NULL , map hstore );
insertHStore :: Connection -> Int -> [(Text,Text)] -> IO Int64 insertHStore conn id map = do execute conn "INSERT INTO hstore_example (id,map) VALUES (?,?)" (id, HStoreList map) retrieveHStore :: Connection -> Int -> IO (Maybe [(Text,Text)]) retrieveHStore conn id xs <- query conn "SELECT map FROM hstore_example WHERE id = ?" (Only id) case xs of  -> return Nothing (Only (HStoreList val):_) -> return (Just val)
Better Error Messages
Jeff Chu and Leonid Onokhov have improved both error messages and error handling options in the latest version. Thanks to Jeff, the
ResultError exception now includes the column name and associated table OID (if any) from which the column was taken from. And Leonid has contributed a new Errors module that can be used to dissect
SqlError values in greater detail.
Better Time Conversions
And in older news, version 0.1.4 debuted brand new time parsers and printers for the ISO-8601 syntax flavor that PostgreSQL emits, included
FromField instances for
LocalTime, and introduced new datatypes for dealing with PostgreSQL’s time infinities. Among other things, the new parsers correctly handle timestamps with UTC offsets of a whole number of minutes, which means (for example) that postgresql-simple now works in India. Version 0.2 removed the conversion from
timestamp (without time zone) to the
ZonedTime types, due to the inherent ambiguity that conversion represents;
LocalTime is now the preferred way of handling timestamps (without time zones).