Martijn van Oosterhout <kleptog@svana.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
