Peter Eisentraut <peter_e@gmx.net> writes:
> But if you look in practice then there are not really any existing
> functions that could benefit from this,
While looking at existing functions can help detect problems in a
proposal like this, the standard set of functions is *not* the be-all
and end-all; the whole point is that we are trying to build an
extensible system. So I'm pretty suspicious of any argument that
begins in the above fashion ;-)
> 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?
A good point; I wouldn't object to returning an error if we determine
that there are multiple equally-good possibilities. But, again, the
sticky question is equally good according to what metric?
> 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.
Most of the cases we will be dealing with in practice are operators of
one or two arguments, so a metric that only has two or three possible
values (respectively) is not going to be very useful... especially
since the exact-match case is not interesting. With the above metric
we'd never be able to resolve any ambiguous unary-operator cases at all!
regards, tom lane
