Re: Casts

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: stark <stark(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Casts
Date: 2006-08-10 14:03:07
Message-ID: 20060810140307.GA14512@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 09, 2006 at 12:21:40PM +0100, stark wrote:
> I think the ideal combination is having every type have precisely one implicit
> cast "up" the type "tree" and assignment casts down the "tree". I don't see us
> every needing anything more complex than a flat "tree" of a single base type
> for each domain and everyone directly a child of that one type. So every
> numeric data type would have an implicit cast to numeric, every text type
> would have an implicit cast to text, etc.

That's basically what we have now, except any numeric type cast be
"upcast" implicity but "downcast" requires assignment. The tree
basically goes like: smallint -> integer -> bigint -> numeric -> real
-> double precision.

You have to be able to cast all the inbetween version implicitly also.
If someone writes an expression with "int2 = int4" you don't really
want to cast them both up to numeric, or worse, double precision.
Currently we can upcast the int2 to int4 implicitly and that allows us
to use an index on the int4 column.

>
> The implicit casts from numeric to other types seem suspect to me. And there
> are tons of cases where we have implicit casts in both directions such as bit
> to varbit and varbit to bit. That makes no sense to me. That would be where
> the surprising effects come from.

The reason for those is basically there is no real difference between bit
and varbit, or character varying and text. Those types are essentially
the same, so why would you want to make a function that treated them
differently?

There are no such round-trips amongst the numeric types.

> As long as every type has precisely one implicit cast up I think it would
> become safe to rely on it for many of the operations and not have to define
> redundant operations for every data type.

You're not required to provide all the casts, but it's user friendly to
do so. Requiring double casts to go between two essentially compatable
types seems silly...

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

In response to

  • Re: Casts at 2006-08-09 11:21:40 from stark

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-08-10 14:14:03 Re: Casts
Previous Message José Orlando Pereira 2006-08-10 14:00:15 Re: standard interfaces for replication providers