It seems odd to me that implicit casts are checked for when you call a
function but not when you're implicitly calling a function via a cast. As a
result there are a *lot* of redundant casts in our catalog, essentially n!
casts for a domain with n types in it. So for example there are 138 casts
between the various numeric data types including every possible pairing of
char, int2, int4, int8, float4, float8, and numeric.
Now I don't think it actually costs us anything to have so many casts but it
sure makes adding new fully functional user defined types a pain. Adding a
single new numeric data type requires creating 12 new casts and a second one
would require 14, etc.
What's strange is that you do not have to go to such lengths to get a fully
functional data type in other respects. One implicit cast to numeric and you
can use +, -, log(), exp(), floor(), ceil(), etc. You may want to implement
some of those for performance reasons but for most relying on the implicit
cast is perfectly reasonable.
It seems like what ought to happen is that every data domain should have a
single blessed data type that is the root data type for that domain. Every
data type in that domain should have a single implicit cast to that root data
type. That effectively is how all the data types are set up in fact. They have
all these dozens of assignment casts and a single implicit cast to a type
chosen in some sort of unspoken consensus.
There has been some fear expressed in the past that too many implicit casts
create surprising side effects. I think that's a valid fear but only relevant
if we have two or more such casts for a single data type or have a cast to an
inappropriate type. As long as we have precisely one implicit cast for every
type and it's a cast to a datatype with basically the same semantics it seems
like we should be safe.
So for example if all the numeric data types had an implicit cast to numeric
and an assignment cast from numeric it ought to be possible for the planner to
find a way to handle an explicit cast between any two arbitrary numeric types
using just those. It could use the same logic it uses to find functions by
looking first for an exact match, then any assignment cast from a data type to
which it can implicitly cast to first.
That would let people add a new fully functional numeric type by creating only
two casts instead of 12. And a second one by creating two more instead of 14,
and so on.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com