stark <stark@enterprisedb.com> writes:
> 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.
This is intentional. If you explicitly cast type foo to type bar there
should not be any question about what function will be invoked. The
cost is a few more rows in pg_cast ... so what? Adding rows to pg_cast
is not the most painful part of making a new datatype.
As for "the parser ought to be able to find two-step cast pathways",
no thanks. The increase in search time and the decrease in
predictability are both undesirable.
> There has been some fear expressed in the past that too many implicit casts
> create surprising side effects.
Not "some fear" ... we have seen people badly burned, time and time
again, by the ill-considered implicit casts that are already in there.
IMHO we need fewer implicit casts, not more.
regards, tom lane