Re: Domains versus polymorphic functions, redux

On Fri, Jun 03, 2011 at 12:27:35AM -0400, Robert Haas wrote:
> But in this case I really don't quite understand why you don't like
> the proposed behavior. AIUI, the case we're talking about is a
> function foo that takes, say, anyarray, and returns anyarray.
>
> Now, let us say we attempt to call foo(bar), bar being a type name.
> What happens? Well, in general, you get back an error saying that no
> such function exists, because bar is not an array type. Certainly if
> bar is int4 or box or a composite type or a domain over a scalar type,
> we are done for. The function call does not match and nothing is left
> to us to throw an error. The only way that this call can possibly
> match is if bar happens to be a domain over an array type,

Correct so far.

> and we
> treat the call as a request to smash bar to the underlying array type.

No, there's no need to do that. The domain "is" an array, not merely something
that can be coerced to an array. Therefore, it can be chosen as the polymorphic
type directly. Indeed, all released versions do this.

> And it seems that is the behavior people want. But once we've done
> that, I don't see why we should then feel compelled to also insert a
> cast in the other direction. In fact, doing so would seem totally
> arbitrary and counterintuitive.

I agree. Both the argument and the return type need to be resolved the same
way, either both as the domain or both as the base array type.