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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
