Martijn van Oosterhout <firstname.lastname@example.org> writes: > My question is whether there should be any implicit casts that are not > safe. Your example int8 -> float8 being implicit is I think an error > and we should wonder why that cast implicit now anyway.
Because the SQL spec requires it. You are not required to write a cast to add an exact and an approximate quantity, and the spec says the result is approximate. Trying to design this stuff purely according to abstract notions of elegance of the cast rules isn't going to work out well --- we have both spec requirements and backwards compatibility to worry about. Now we do have the flexibility to alter the default contents of pg_cast --- there could be more or fewer entries in there than there are now, if the type coercion rules are altered to do less or more automatically than they do now. But the end-result behavior needs to wind up being pretty darn near the same thing, at least within the numeric type category (I'm not as certain that we have the other ones right, but the numeric category has been *very* heavily scrutinized and beat upon). The only thing I really want to see changing is the behavior for domain types --- and even there, the "default" behavior when there are no user-created domain-specific operators or casts has to stay the same. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings