From: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Maurice Gittens <mgittens(at)gits(dot)nl> |
Cc: | Dave Chapeskie <dchapes(at)ddm(dot)on(dot)ca>, Postgres Hackers List <hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Automatic type conversion |
Date: | 1998-05-11 04:14:46 |
Message-ID: | 35567B36.39D47B5A@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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?
> 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.
> >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...
- Tom
From | Date | Subject | |
---|---|---|---|
Next Message | Tak Woohyun | 1998-05-11 04:16:26 | Re: [HACKERS] Help me!!! Please |
Previous Message | Bruce Momjian | 1998-05-11 03:26:59 | mmap and MAP_ANON |