 From looking at the set of implicit or not casts, I think there are two
major issues to discuss:

1. Should truncating/rounding casts be implicit?  (e.g., float4 -> int4)

I think there's a good argument for "no", but for some reason SQL99 says
"yes", at least for the family of numerical types.

2. Should casts from non-character types to text be implicit?  (e.g., date
-> text)

I think this should be "no", for the same reason that the other direction
is already disallowed.  It's just sloppy programming.

I also have a few individual cases that look worthy of consideration:

abstime <-> int4:  I think these should not be implicit because they
represent different "kinds" of data.  (These are binary compatible casts,
so changing them to not implicit probably won't have any effect.  I'd have
to check this.)

date -> timestamp[tz]:  I'm suspicious of this one, but it's hard to
explain.  The definition to fill in the time component with zeros is
reasonable, but it's not the same thing as casting integers to floats
because dates really represent a time span of 24 hours and timestamps an
indivisible point in time.  I suggest making this non-implicit, for
conformance with SQL and for general consistency between the date/time
types.

time -> interval:  I'm not even sure this cast should exist at all.
Proper arithmetic would be IntervalValue = TimeValue - TIME 'midnight'.
At least make it non-implicit.

timestamp -> abstime:  This can be implicit AFAICS.

-- 
Peter Eisentraut   peter_e@gmx.net


Thu, 25 Jul 2002 22:56:02 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Which casts should be implicit
> date -> timestamp[tz]:  I'm suspicious of this one, but it's hard to
> explain.  The definition to fill in the time component with zeros is
> reasonable, but it's not the same thing as casting integers to floats
> because dates really represent a time span of 24 hours and timestamps an
> indivisible point in time.  I suggest making this non-implicit, for
> conformance with SQL and for general consistency between the date/time
> types.

Althought I'm sure there's _loads_ of people using this conversion,
including me in various random places in the codebase.

Chris


Fri, 26 Jul 2002 10:38:24 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: Which casts should be implicit
> > date -> timestamp[tz]:  I'm suspicious of this one, but it's hard to
> > explain.  The definition to fill in the time component with zeros is
> > reasonable, but it's not the same thing as casting integers to floats
> > because dates really represent a time span of 24 hours and timestamps an
> > indivisible point in time.  I suggest making this non-implicit, for
> > conformance with SQL and for general consistency between the date/time
> > types.
>
> Althought I'm sure there's _loads_ of people using this conversion,
> including me in various random places in the codebase.

Actually, if inserting counts as an explicit conversion, then maybe not...


Fri, 26 Jul 2002 13:49:04 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: Which casts should be implicit