Array types
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)
TypeInfo Changes
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 FromField
and FromRow
instances by accessing the data constructor of the Conversion
monad via the Database.PostgreSQL.Simple.Internal
module.
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 FromField
and 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.
HStore support
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 UTCTime
and ZonedTime
types, due to the inherent ambiguity that conversion represents; LocalTime
is now the preferred way of handling timestamps (without time zones).