Re: Prefered Types - Mailing list pgsql-hackers

Robert Haas <robertmhaas@gmail.com> writes:
> ... One of the big, fat problems
> with typispreferred is that it totally falls apart when more than two
> types are involved.  For example, given a call f(int2), we can't
> decide between f(int4) and f(int8), but it seems pretty clear (to me,
> at least) that we should prefer to promote as little as possible and
> should therefore pick f(int4).

Yeah.  If your mental model is one of "least promotion", you really
cannot express that at all with a "preferred type" concept, even if the
ratings are integers and not bools.  On the other hand, it does seem
possible to attach a "cost" or "distance" metric to casts and get some
reasonably intuitive behavior that way.  If you check the archives I
believe we've discussed this before using the "distance" terminology.
It still falls down though on the question of what to prefer when there
are several combinations of multiple casts to choose between.  And as
you say it's not entirely clear how well either approach generalizes to
after-the-fact insertion of new types/casts in the hierarchy.

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.

> It's not clear to me whether in any of this there is a solution to the
> problem of int2 being a second-class citizen.

I've always felt that the basic problem int2 has got is that the parser
initially types integer-looking constants as int4 or larger, even if
they'd fit in int2.  If it typed them as int2 then the unintuitive
behaviors would largely go away, without any need for allowing implicit
down-casting from int4 to int2.  I actually tried that once, probably
close to ten years ago, and it blew up real good because many cases that
formerly were considered an exact match no longer were, and the parser
started making some pretty surprising (or at least not backwards
compatible) resolution choices.  Maybe with a more controllable
type-promotion mechanism we could get better results there.

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.  If the new behavior
is really significantly better *for users* then we can probably
withstand the complaints; but if it's just marginal improvements or just
improves life for hypothetical future extensions, it's not going to fly.
        regards, tom lane