I see that default mapping for DateTime .net type to PostgreSQL is date. While it is datetime for SQL Server. I wonder why's that since PostgreSQL's date contains only date part, not time. I guess the correct mapping would be timestamp?

http://www.postgresql.org/docs/current/static/datatype-datetime.html

timestamp doesn't contain date info, so why would timestamp be the right type?

Otis wrote:

timestamp doesn't contain date info, so why would timestamp be the right type?

Check the given URL

timestamp: both date and time (no time zone) date: date (no time of day)

mihies wrote:

Otis wrote:

timestamp doesn't contain date info, so why would timestamp be the right type?

Check the given URL

timestamp: both date and time (no time zone) date: date (no time of day)

Oh Postgresql timestamp type you mean, I thought you meant .NET timestamp type.

They actually have timestamp (date+time) and time (only time). Funny naming.

There are several types mapping to .NET datetime, so we have to pick one for the 'default', we sort them based on a pre-defined ordering in the driver.

This is of course not always ideal (a lot of people want to use just date values but not everyone), and it would be great if this was editable.

In v5 we've added a way to specify a custom typeshortcut with a preferred db type. So that would solve this problem: you can then specify a new typeshortcut for .NET DateTime with the db type 'Timestamp' or 'Timetz' if you want, whatever you like, and forward (model first) mappings will then pick that db type for fields using that typeshortcut. I think this is added after CTP2.

Ah, OK. Editable is always good. Hopefully that's per database type, right?

mihies wrote:

Ah, OK. Editable is always good. Hopefully that's per database type, right?

per shortcut, per database, it's an additional element you can specify for a default on a typeshortcut, so you can create as much typeshortcuts for the .NET DateTime type as you want, each with a different target type in the DB, so you can specify the target types using fine-grained precision