Noah Misch <n...@leadboat.com> writes: > On Fri, Jun 03, 2011 at 12:27:35AM -0400, Robert Haas wrote: >> 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. No, it cannot "be chosen as the polymorphic type directly". The problem with that is that there is no principled way to resolve ANYELEMENT unless you consider that you have downcasted the domain to the array type. You could perhaps ignore that problem for polymorphic functions that use only ANYARRAY and not ANYELEMENT in their arguments and return type --- but I'm not happy with the idea that that case would work differently from a function that does use both. So far as the other points you raise are concerned, I'm still of the opinion that we might be best off to consider that domains should be smashed to their base types when matching them to ANYELEMENT, too. Again, if we don't do that, we have a problem with figuring out what ANYARRAY ought to be (since we don't create an array type to go with a domain). More generally, this dodges the whole problem of needing polymorphic functions to enforce domain constraints, something I still believe is entirely impractical from an implementation standpoint. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers