On Wed, Aug 04, 2004 at 12:48:57AM -0400, Tom Lane wrote:
> "Jim C. Nasby" <decibel@decibel.org> writes:
> > ... I'd like to know
> > if there is a specific reason there's no default timestamp -> varchar
> > cast.
>
> There is an explicit cast from timestamp to varchar, at least in recent
> releases:
>
> regression=# select 'now'::timestamp::varchar;
> varchar
> ---------------------------
> 2004-08-04 00:42:05.34875
> (1 row)
>
> 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). I would argue that any
conversion where you won't lose information (ie: timestamp to text) is
OK.
In any case, turned out that wasn't my problem anyway...
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>
--
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?"