Re: [HACKERS] Automatic type conversion

-----Original Message-----
From: Thomas G. Lockhart <lockhart@alumni.caltech.edu>
To: Maurice Gittens <mgittens@gits.nl>
Cc: Dave Chapeskie <dchapes@ddm.on.ca>; Postgres Hackers List
<hackers@postgresql.org>
Date: maandag 11 mei 1998 12:24
Subject: Re: [HACKERS] Automatic type conversion


>> Making an int from a float is only defined for "small" values of the
>> float. So for the general case such a conversion would simply overflow
>> the int, giving it an undefined value. Does this make sense to you?
>
>Yes, it does. Look, I'm not saying everyone _should_ call factorial with
>a float, only that if someone does, Postgres will try to accomplish it.
>Doesn't it make sense to you?

IMO the issue is not related to the factorial function. I think we
are/should
be discussing the general issue how to handle conversions from a type A to
a type B while the conversion function F from A to B is not defined
for all values of A.

>
>> Are conversions between types defined in a way that is also
>> extensible? I'm trying to say that if I add a new type to the system,
>> can I also specify which conversions are automatically allowed?
>> (Something similar to the C++ "explicite" keyword?).
>
>Yes, they are extensible in the sense that all conversions (except for a
>few string type hacks at the moment) are done by looking for a function
>named with the same name as the target type, taking as a single argument
>one with the specified source type. If you define one, then Postgres can
>use it for conversions.
>
>At the moment the primary mechanism uses the pg_proc table to look for
>possible conversion functions, along with a hardcoded notion of what
>"preferred types" and "type categories" are for the builtin types. For
>user-defined types, explicit type conversion functions must be provided
>_and_ there must be a single path from source to possible targets for
>the conversions. Otherwise there will result multiple possible
>conversions and Postgres will ask you to use a cast, much as it does in
>v6.3.x and before.

Thanks for the explanation.

>
>> >Or, again for this factorial case, we can implement a floating point
>> >factorial with either the gamma function (whatever that is :) or with
>> >an explicit routine which checks for non-integral values.
>> And properly handles overflows.
>
>Hey, it doesn't do any worse than before...
I don't know what the system used to do. I do however hope
that if a conversion is not defined that the system won't simply ignore
the error.

Don't worry I'll shut up now.

With regards from Maurice.