stark <[EMAIL PROTECTED]> writes: > I think the ideal combination is having every type have precisely one > implicit cast "up" the type "tree" and assignment casts down the > "tree".
No, because for example in the case of the numeric datatypes, that would result in *every* cross-type operation being done in NUMERIC. Do you really want, for example, "bigint var = integer constant" to be interpreted as "var::numeric = const::numeric"? (Hint: you'll lose the benefit of any index on the var.) Actually it's worse than that, because the top of the numeric datatype hierarchy is float8 not numeric; this is more or less forced by SQL's rules about exact vs inexact arithmetic. So your proposal would really reduce to doing all cross-type arithmetic in float8 ... which would at least be a lot faster than numeric, but it's not gonna fly from an accuracy point of view. What we want, and what the existing pg_cast rules give us, is a rule that an operation between two different numeric types is done in the "wider" of those two types. You could probably propose some explicit representation of this concept that would be more compact than the present pg_cast table --- but it would also be less flexible. I don't really see much to be gained that way. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match