Re: Casting timestamp with time zone to varchar automatically

On Wed, Aug 04, 2004 at 01:57:12PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <decibel@decibel.org> 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 :-(

Would it maybe make more sense to change things so that implicit casts
aren't used for comparisons? Maybe instead of the simple 3-tier system
of what casts can do there should be a bitmap that specifies if a cast
can happen implitily for function calls, column assignments, and/or
comparisons.
--
Jim C. Nasby, Database Consultant               decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"