Re: casts and conversions
От | Ross J. Reedstrom |
---|---|
Тема | Re: casts and conversions |
Дата | |
Msg-id | 20010617210203.A10168@rice.edu обсуждение исходный текст |
Ответ на | casts and conversions (Craig Longman <craigl@begeek.com>) |
Ответы |
Re: casts and conversions
|
Список | pgsql-sql |
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
В списке pgsql-sql по дате отправления: