Reading the subject, "creepy ... dates", that is exactly how I feel
about the described current date behavior --- "creepy".
Because I have only seen one person defend our current behavior, and
many object, I am going to add to TODO:
* Allow current datestyle to restrict dates; prevent month/day swapping
from making invalid dates valid
* Prevent month/day swapping of ISO dates to make invalid dates valid
I know someone was mentioning how bad it was that MySQL allows NULL in a
NOT NULL date field, and inserts 00-00-0000. I think we are pretty
close to that with our current behavior.
---------------------------------------------------------------------------
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > It would make sense to offer a "strict" mode in which the date order
> > has to be what DateStyle suggests. I'm astonished that no one seems
> > to get the point that there are also good uses for "lax" parsing.
>
> There are different kinds of lax parsing.
>
> Lax parsing is great if you can enter any of
>
> January 8, 1999
> 1999-01-08
> 1/8/1999
> 990108
> January 8 04:05:06 1999 PST
>
> and it will know what you mean, because of all these have their uses and
> are unambiguous (given a known day/month order).
>
> But automatically switching the declared day/month order based on
> heuristics is not that great. A human is not going to mentally switch his
> preferred day/month order within the same SQL session.
>
> --
> Peter Eisentraut peter_e@gmx.net
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
