On Thu, Jun 2, 2011 at 8:25 PM, Noah Misch <n...@leadboat.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
