Re: Prefered Types

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 2011/5/4 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> Perhaps it would be adequate to allow automatic resolution of an
>> overloading conflict only when one of the available alternatives
>> dominates all others, ie, none of the argument positions requires a
>> "longer distance" cast than is used in that position by any other
>> available alternative. I'm just throwing that out as a possibility,
>> I haven't tried it.

> That works OK for most things, but there's one case where I think we
> might need a better solution - suppose A is a subtype of B. It's
> fairly common to define a function or operator f(A,A) and f(B,B), and
> to want f(A,B) or f(B,A) to be interpreted as a the latter rather than
> the former. For example, let A=int2, B=int4, f=+. Now, we can (and
> currently do) handle that by just defining all the combinations
> explicitly, but people don't always want to do that.

That case still works as long as downcasts (int4 -> int2) are either not
allowed to be invoked implicitly at all, or heavily penalized in the
distance assignments.

>> BTW, not to rain on the parade or anything, but I'll bet that
>> rejiggering anything at all here will result in whining that puts the
>> 8.3-era removal of a few implicit casts to shame.

> Yeah, I share that fear, which is why I think the idea of generalizing
> typispreferred to an integer has more than no merit: it's less likely
> to break in ways we can't anticipate.

Well, if you change it to an int and then don't change any of the values
from what they were before, I agree. But then there's no point.
Presumably, the reason we are doing this is so that we can assign some
other preferredness values besides 0/1, and that will change the
behavior. We'd better be damn sure that the new behavior is really
better. Which is why it seems a bit premature to be working on an
implementation when we don't have even a suggestion as to what the
behavioral changes ought to be.

regards, tom lane