> 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.
Trying to solve this problem requires more investigation having spec
requirements and backwards compatibility etc.. etc.. in mind.
After reading the thread, I think there are some interesting
similarities, ideas (or even techniques) used in OO languages like JAVA
and C# regarding internal handling when type boxing and type casting. (I
would like to think domains as inherited classes of their super or the
base class.)
I will come back with more thoughts after I have investigated a thing or
two. Say tuned....
