
-----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.



Mon, 11 May 1998 09:44:51 +0200
"Maurice Gittens" <mgittens@gits.nl>
Re: [HACKERS] Automatic type conversion
> Don't worry I'll shut up now.

Well, try things out if you have time and see if things work in general.
It took me quite some time to work through the issues and we'll need to
try many cases and have some back-and-forth discussion before everything
is clear and we can determine what adjustments should be made.

fyi, the original SQL developers for Postgres seemed to be divided on
the subject, but one camp concluded that almost no automatic type
conversion was desirable. I think in practice that this is too extreme,
since many cases have an obvious best conversion strategy...

                      - Tom

Mon, 11 May 1998 14:47:09 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] Automatic type conversion