Domains versus polymorphic functions, redux

In http://archives.postgresql.org/pgsql-bugs/2011-05/msg00171.php
Regina Obe complains that this fails in 9.1, though it worked before:

regression=# CREATE DOMAIN topoelementarray AS integer[];
CREATE DOMAIN
regression=# SELECT array_upper(ARRAY[[1,2], [3,4]]::topoelementarray, 1);
ERROR: function array_upper(topoelementarray, integer) does not exist

This is a consequence of the changes I made to fix bug #5717,
particularly the issues around ANYARRAY matching discussed here:
http://archives.postgresql.org/pgsql-hackers/2010-10/msg01545.php

Regina is the second or third beta tester to complain about domains over
arrays no longer matching ANYARRAY, so I think we'd better do something
about it. I haven't tried to code anything up yet, but the ideas I'm
considering trying to implement go like this:

1. If a domain type is passed to an ANYARRAY argument, automatically
downcast it to its base type (which of course had better then be an
array). This would include inserting an implicit cast into the
expression tree, so that if the function uses get_fn_expr_argtype or
similar, it would see the base type. Also, if the function returns
ANYARRAY, its result is considered to be of the base type not the
domain.

2. If a domain type is passed to an ANYELEMENT argument, automatically
downcast it to its base type if there is any ANYARRAY argument, or if
the function result type is ANYARRAY, or if any other ANYELEMENT
argument is not of the same domain type. The first two cases are
necessary since we don't have arrays of domains: the match is guaranteed
to fail if we don't do this, since there can be no matching array type
for the domain. The third case is meant to handle cases like
function(domain-over-int, 42) where the function has two ANYELEMENT
arguments: we now fail, but reducing the domain to int would allow
success.

An alternative rule we could use in place of #2 is just "smash domains
to base types always, when they're matched to ANYELEMENT". That would
be simpler and more in keeping with #1, but it might change the behavior
in cases where the historical behavior is reasonable (unlike the cases
discussed in my message referenced above...) I find this simpler rule
tempting from an implementor's standpoint, but am unsure if there'll be
complaints.

Comments, better ideas?

regards, tom lane