Re: Implicit coercions, choosing types for constants, etc

Tom Lane writes:

> One way to fix this is to make cross-category coercions to text not be
> implicit casts. (I've opined before that that's a bad idea, but not
> gotten a lot of support for changing it. Now that we have a distinction
> between implicit and assignment casts, perhaps we could consider making
> coercions to text be assignment casts, as a compromise?)

I thought we had agreed to make those explicit. In fact, I vaguely recall
you not liking that notion ...

> I suppose we could fix this particular case by eliminating
> to_hex(integer), or adding to_hex(smallint), but that seems a very
> unsatisfying answer. I am wondering about adding some notion of
> "conversion distance" associated with casts, and preferring choices
> that require a smaller conversion distance; perhaps this could replace
> the concept of "preferred type", too. But again I don't have a specific
> proposal to make. Any thoughts?

A couple of months ago I played around with the notion of adding a numeric
preference ("distance", as you call it) to the casts, but in the end this
solved only a small number of cases and created a big mess at the same
time. When you have to pick arbitrary distances, any algorithm will give
you arbitrary answers, after all.

I think we can construct a type precedence list using the existing catalog
information. Considering the example of choosing between int2->int4 and
int2->int8, the system could notice that there is an implicit cast
int4->int8 (and no implicit cast the other way), so int4 is "less" than
int8. (If there were an implicit cast int8->int4, then the system would
have to consider int4 and int8 to be equivalent and picking one at random
would be reasonable.)

--
Peter Eisentraut peter_e(at)gmx(dot)net