Tom Lane writes:
> If there are multiple possibilities, we choose the one which is the
> "least promoted" by some yet-to-be-determined metric.
A "metric" is often one step away from "unpredictable behaviour", at least
for users.
But if you look in practice then there are not really any existing
functions that could benefit from this, at least not if the other
proposals go through and/or a few function entries are added or removed.
Let's say you have a function foo(float8, int2) and one foo(float4, int8)
and you call it with (you guessed it) float4 and int2. Which do you take?
If there is a good reason that these two functions exist separate in the
way they are then the decision should probably not be made by some
casting-cost metric but by the user. If there is no good reason that the
functions are like this then perhaps the implementator should be made
aware of the (useless?) ambiguity and maybe provide a grand unified
(float8, int8) version.
If you do want to support this sort of ambiguity resolution then the
metric should IMHO be how many arguments you had to cast away from the
input type at all. That *might* give reasonable behaviour for users,
though I'm not completely sure.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
