On Sat, Jun 16, 2001 at 01:07:29AM -0400, Craig Longman wrote:
<problem wiuth no automatic float8<->numeric casts>
Tom Lane has already addressed the 'why is it this way' question. I'll
address your proposed work arounds.
>
> the only solution i can think of, if it is possible, is to have a script
> that the client would need to run to declare the missing parameter
> combinations for the standard operators. this isn't very desireable,
> but it is the only real solution i can see so far. any other
> suggestions?
Yup, that's pretty much the only way to do this. Either run scripts as
part of the install, or (if there's a logical place for it in the workflow)
you could much around to see if the declarations are already there, and only
run the script if their missing.
>
> why does this happen? i have run into this before, and was able to
> perform the explicit cast (the code was postgresql only), but it seems
> like this is always going to be a problem, unless i'm missing something.
> are there plans for more thorough dynamic-casting logic, or does one
Check the HACKERS archives: there've been _long_ discussions about how to
do dynimic casting correctly, in the face of a user extensible type system.
Not trivial, at all.
> just need to go through all the combinations of datatypes and make sure
> that every combination is entered in the operator mapping tables? i
> guess it would need to be entered both ways also ( int*float8,
> float8*int )?
I'd test with all the combinations of types you need, then only add
enough new mappings to get everything working.
Ross