If you're using Postgres you can use types in the database http://www.postgresql.org/docs/9.2/static/sql-createtype.html

I don't know what these look like from the Haskell drivers but you can have typed SQL if you want it.

On Tuesday, February 10, 2015, Nikita Karetnikov <nikita@karetnikov.org> wrote:

> That part I don't understand.  Why does your proposal require varchars
> everywhere?

That's what Persistent generates (using derivePersistField) for the
second table.  For example, the Haskell value

MyText "foo"

where MyText is

newtype MyText = MyText Text deriving (Show, Read)
derivePersistField "MyText"

will be stored in PostgreSQL as a varchar

'MyText "foo"'

I assume that Persistent (or its PostgreSQL backend) has a predefined
mapping from a commonly used Haskell types to the database types.
And everything else is represented as a varchar.

So there are two choices, corresponding to the two tables shown in the
original message:

1. Design tables with the (basic) database types in mind (integer,
   boolean, timestamp, varchar, etc.) then wrap and unwrap values each
   time you interact with the database.

2. Use Haskell types like MyText or something more complex directly
   and end up with varchar everywhere.

I wonder how bad is the second option in practice because
wrapping/unwrapping is error-prone.  Of course, the varchar thing makes
the alarm bells ring in my head, but when does it significantly affect
performance?  For example, maybe it's okay for a small shop, or is it a
no go for everyone?

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe