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.
