Re: Casting timestamp with time zone to varchar automatically

"Jim C. Nasby"  writes:
> On Wed, Aug 04, 2004 at 12:48:57AM -0400, Tom Lane wrote:
>> Whether this should be invokable implicitly is somewhat of a theological
>> issue, but personally I'm agin it.  My experience is that implicit
>> cross-type-category casts are Bad News All Around because they tend to
>> happen when you weren't expecting it, resulting in quite surprising
>> behavior.  (An implicit cast from, say, timestamp to date is far less
>> dangerous.)  You can find lots of discussion about related issues in
>> the list archives.

> Actually, my experience has been that the real issue isn't cross-type,
> it's loss of information. For example, automatically casting a timestamp
> to a date means you lose information; if this happens automatically you
> can be in for a very unpleasant surprise (I was recently bit by this
> when doing division of a double or a numeric and having it get converted
> to an int because I was dividing by an int).

Yeah, that is certainly bad, but cross-category is bad news for different
reasons.  The sort of example I've seen come up again and again is that
someone compares a foo to a bar and files a bug report because the
comparison is behaving in a wacko fashion.  On investigation it turns
out that there is no foo-to-bar comparison operator, but the system
decided it could implicitly cast both of them to text and do a textual
comparison.  The behavior is perfectly sensible when seen as a text
comparison but made no sense in terms of the original datatypes'
semantics.  Type casts within a category tend not to have such problems
because, for example, timestamps and dates sort compatibly in any case.

So I do not like implicit casts to text from non-textual datatypes, and
would like to get rid of the ones we have rather than introduce more.

I think we have already cleaned up all the cases where
information-losing casts were marked implicit, but we still have some
implicit casts to text :-(

			regards, tom lane