On Wed, 23 Jan 2002, Bill Studenmund wrote:
What I was getting at was that Tom's behavior (or even mine) is more
similar to the currently described behavior than the suggested one.
> > > made the call ambiguous, you wanted the coercion to happen. Or at least
> > > you weren't concerned that it might.
> >
> > I still disagree. If I make a complex number type in my schema,
> > I don't really intend integer+integer to convert to complex and give me a
> > complex answer even if I want to be able to cast integers into complex.
> > AFAIK there's no way to specify that I want to make the function
> > complex(integer) such that I can do CAST(1 as complex) but not as an
> > implicit cast.
>
> Note: I've been talking about functions, and you're talking about
> operators. While operators are syntactic sugar for functions, one big
> difference is that you can't specify explicit schemas for operators (nor
> do I think you should be able to). I think exact matches for operators
> anywhere in the path would be better than local coercable ones.
I'd say the same thing for a random math function as well. For example
if there was a square(int) that returned $1*$1 and I made a square for my
complex type, I'd still expect that square(5) is an integer rather than a
complex using the square(complex). For example, I'd expect square(5) to
be a valid length argument to substr.
> Does SQL'99 say anything about this?
That I don't know about (don't have a draft around to look at). I'm not
sure that it'd have these problems though unless it's got the same sort of
coercion system.
