On Wed, Sep 20, 2006 at 10:56:08AM -0700, Mark Dilger wrote: > If the system chooses cast chains based on a breadth-first search, then the > existing int2 -> int8 cast would be chosen over an int2 -> int4 -> int8 > chain, or an int2 -> int3 -> int4 -> int8 chain, or in fact any chain at > all, because the int2 -> int8 cast is the shortest.
But we're not talking about a search here, we don't always know where the endpoint is. Imagine you have the following three functions: abs(int8) abs(float4) abs(numeric) And you have an int2. Which is the best cast to use? What's the answer if you have a float8? What if it's an unknown type text string? Now, consider that functions can have up to 32 arguments and that this resolution might have to be applied to each argument and you find that searching is going to get very expensive very quickly. The current system of requiring only a single step is at least predictable. If you have the choice between: - first argument matches, second needs three "safe" conversions, and - first argument need one "unsafe" conversion, second matches exactly Which is cheaper? To make this manageable you have to keep the number of types you can cast to small, or you'll get lost in the possibilites. Adding just a single step domain to base type conversion seems pretty safe, but anything more is going to be hard. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate.
signature.asc
Description: Digital signature
