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

On Tue, 29 Jul 2003, Dmitry Tkach wrote:

> 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 mind an explicit conversion as much because at least you know
that you're getting it. Implicit conversions mean that a user has no
reason to know (apart from name in this case) that the query should fail
if you put 'T' in the column whereas a query like textcol::date is a
pretty big hint.

> 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 don't have to do one for every combination of types, only one for the
reasonable ends of casting chains that make sense.

The problem with downcasts is that the source type doesn't (always/often)
give you reasonable values in the destination type. int8->int2 for
example is probably unspecified behavior in C (for the signed type) for
almost all values in int8. You can call that short function with your
long long, but the value you get in isn't likely to be what you expect in
most cases.

> >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...

I guess the problem is that I don't agree. To me timestamps and dates are
different but related things. I'll agree that a timestamp may contain a
date or the data that a date contains, though. ;)

> >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.... :-)

No. I meant explicit in the C++ meaning, the constructor is not considered
for implicit conversions but is available to be called explicitly like
Date(timestampval).