-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Advertising
> This cannot be right can it? The code used to check EuroDates and now
> it doesn't. ISTM you must have broken either Euro or US format.
I'm not sure of the final consensus on what exactly the behavior should be.
> Also, I thought that the consensus on -general was that the heuristics
> involving looking at the range of the values were a bad idea. (While
> I disagree, I can recognize a lost cause when I see one.) You've still
> got them in there. ISTM the code ought to assume MM before DD if ISO
> or Euro style, otherwise (US style) assume DD before MM, and then reject
> if out of range, rather than allowing the range to determine which is
> which.
The ranges are only in there as an earlier catch of an invalid date - they
no longer are part of the earlier logic which allowed a "pass-through."
They should be removeable with no effect. I'll write up a new patch.
Does this logic seem correct?
if (US) {
YYYY-MM-DD
MM-DD-YYYY
}
else {
YYYY-MM-DD
DD-MM-YYYY
}
In other words, the US is backwards from the rest of the world.
(as far as MM-DD-YYYY)
Thanks,
- --
Greg Sabino Mullane [EMAIL PROTECTED]
PGP Key: 0x14964AC8 200306251031
-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html
iD8DBQE++bdlvJuQZxSWSsgRArcZAKD4+VO8yK6LeOYszPHL9Kp2Ol4HaQCg4Ovf
wv8M/bvlzeACu6/ow8RpvoQ=
=Dgns
-----END PGP SIGNATURE-----
---------------------------(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
