Stephan Szabo wrote:
>The first doesn't, date_pli('foo', 2) that's just text->date
>
But you can't cast 'foo' into date, can you? I mean, there is a cast,
but it will fail, right.
And if you used a valid date textual representation, then, I don't see
any reason why
date_pli ('29/07/03', 2) should not work
And, as a matter of fact, it *does*, unless you add '::text' to it (in
7.3 - 7.2 is still OK with it).
> (the other
>does, but it was a more rediculous example using two casts - I don't
>see much stretch from allowing all casts implicitly to allowing multiple
>casts really in the abstract anyway)
>
Well... I don't know about the 'stretch' :-)
I am just trying to use the analogy with programming language (like C++,
or Java) that allow function/operator overloading - they do allow
single-step casts (as long as it is no ambigous), but not multiple step
... they also allow downcasting (e.g. using a superclass of the declared
argument argument), even for "primitive" types actually (it will
implicitly coerce a double into an int for example if you send it into a
function that expects an int, even though it will complain about it
first, which, BTW I believe to be inconsistent - if you can coerce a
subclass into a superclass, there is not much difference in casting
double into an int really)...
So, I just have a little trouble understanding why postgres cannot use
those same rules, and has instead to "reinvent the bycicle" and come up
with some of its own...
Dima
