If you're using Postgres you can use types in the database <a href="http://www.postgresql.org/docs/9.2/static/sql-createtype.html">http://www.postgresql.org/docs/9.2/static/sql-createtype.html</a><div><br></div><div>I don't know what these look like from the Haskell drivers but you can have typed SQL if you want it.<br><br>On Tuesday, February 10, 2015, Nikita Karetnikov <<a href="mailto:nikita@karetnikov.org">nikita@karetnikov.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> That part I don't understand.  Why does your proposal require varchars<br>
> everywhere?<br>
<br>
That's what Persistent generates (using derivePersistField) for the<br>
second table.  For example, the Haskell value<br>
<br>
MyText "foo"<br>
<br>
where MyText is<br>
<br>
newtype MyText = MyText Text deriving (Show, Read)<br>
derivePersistField "MyText"<br>
<br>
will be stored in PostgreSQL as a varchar<br>
<br>
'MyText "foo"'<br>
<br>
I assume that Persistent (or its PostgreSQL backend) has a predefined<br>
mapping from a commonly used Haskell types to the database types.<br>
And everything else is represented as a varchar.<br>
<br>
So there are two choices, corresponding to the two tables shown in the<br>
original message:<br>
<br>
1. Design tables with the (basic) database types in mind (integer,<br>
   boolean, timestamp, varchar, etc.) then wrap and unwrap values each<br>
   time you interact with the database.<br>
<br>
2. Use Haskell types like MyText or something more complex directly<br>
   and end up with varchar everywhere.<br>
<br>
I wonder how bad is the second option in practice because<br>
wrapping/unwrapping is error-prone.  Of course, the varchar thing makes<br>
the alarm bells ring in my head, but when does it significantly affect<br>
performance?  For example, maybe it's okay for a small shop, or is it a<br>
no go for everyone?<br>
</blockquote></div>