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

Reply via email to