Re: help: now() + N is now failing!

Stephan Szabo wrote:

>On Tue, 29 Jul 2003, Dmitry Tkach wrote:
>
>
>
>>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).
>>
>>
>
>That's because it's actually unknown, not text.
>
I know :-)

> But, should
>date_pli(textcolumn, 2) work if and only if all the values of the column
>happen to be date like? That's pretty brittle and even more so since
>there's no obvious conversion being done.
>
Well... This sounds like a different topic alltogether to me -
generally, the question is should it be possible at all to *cast*
(whether explicitly or implicitly) type A into type B when the
conversion is only possible for a small subset of possible values of type A.
I mean, something like parse_date(text) is fine, but textcolumn::date
is, indeed, questionable.

I don't really know the answer to this question (but I do lean toward
the position, that conversions like this should not be possible as casts
per se)...

But my point is that if you can (unambigously) cast a value into a
target type, then in the tradition of commonly used programming
languages, it would be reasonable to expect it to be possible to invoke
a function that expects that type as an argument with the original value
as a parameter, and have it get casted implicitly to match the function
declaration.

My understanding is that this was, pretty much, the whole idea behind
the 'polymorphism', and function overloading in general -
you define an 'operator +' for your basic types, and expect it to work
on anything you send in... Having to define it separately for every
possible combination of types (and having the code do the exact same
thing in most of the cases) kinda defeats the purpose, doesn't it?

>
>You use an example of C++ and inheritance, but Timestamp is not a subclass
>of Date or vice versa.
>
I knew, you'd say that :-)
That example was meant as just an analogy.
The timestamp being or not being a subclass of date is an implementation
detail. From the user's standpoint, for all intents and purposes, it
*is* - timestamp is a date, with some additional information...

>Effectively we have a Date(Timestamp) explicit
>constructor.
>
Ok, that beats your previous point, right? :-)
I mean, in C++ it is enough to have a constructor like that defined,
even if timestamp is not not a subclass of date, it can still be
implicitly converted, as long as the constructor is defined.... :-)

>You can't call a date expecting function with a timestamp
>because the conversion is not legal unless explicitly made. And C++ at
>least does allow multiple conversions, just not multiple user-defined
>conversions (for example int->double, double->classtype is allowed).
>
>
>
Yep. You are right, I forgot about that...
Well.. perhaps, postgres should allow that too eventually then :-)
But, just allowing single-step conversions for now would be agood
starting point anyway... :-)

Dima