Re: Domains versus polymorphic functions, redux

On Thu, Jun 2, 2011 at 8:25 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> I don't doubt that's usable, and folks would find the behavior of their
> applications acceptable given that approach.  However, it's an arbitrary (from
> the user's perspective) difference in behavior compared to the interaction of
> polymorphic functions with domains over scalars.  You did propose removing that
> inconsistency, but that just builds up a fresh inconsistency between domains
> over scalars and plain scalars.  And for what gain apart from implementation
> ease or performance improvements?

Perhaps this is stating the obvious, but implementation ease and
performance improvements can sometimes be non-trivial benefits.

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, and we
treat the call as a request to smash bar to the underlying array type.
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 mean, suppose bar is a domain over int[]. If the user had called
foo(some_bar_value::int[]), what should the return type be?
Presumably int[], no? If he called
foo(some_bar_value::int[]::numeric[]), then the return value should be
numeric[], I would think. So if he just calls foo(some_bar_value),
what should the return type be? Well, again, to make the function
call match at all, we have to insert a cast there... otherwise the
input is not of an array type and the call should just fail. And once
we've inserted the cast, then ISTM that we're bound to make the return
type match the cast we stuck in there.

I might be all wet here... but that's how it seems to me ATM.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company