On Wed, 23 Jan 2002, Stephan Szabo wrote:
> On Wed, 23 Jan 2002, Bill Studenmund wrote:
>
> > On Wed, 23 Jan 2002, Stephan Szabo wrote:
> >
> > Yes, you did. The documentation said that that would happen, so since you
>
> It doesn't currently say anything of the sort. If we made the above
> behavior the standard, it would, but that's sort of circular. ;) Unless
> I'm misreading the page Tom sent me to earlier, it seems to say it
> prefers matches with exact types over coercions which would no longer be
> true.
The documentation says nothing about schemas at all now, so obviously it
has to change. :-)
> > 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.
Does SQL'99 say anything about this?
Take care,
Bill
