But does it (that is, having varchars everywhere) significantly affect performance in practice? If it depends, then when is it a reasonable price to pay?

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?

You shouldn't be using derivePersistField here if you want another db type. As you say there is a predefined mapping but you can override this by defining custom instances for your newtype. On Tue, Feb 10, 2015 at 7:11 PM, Bob Ippolito wrote:

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 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