Domains versus polymorphic functions, redux

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Cc: lr(at)pcorp(dot)us
Subject: Domains versus polymorphic functions, redux
Date: 2011-05-24 16:12:55
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Regina Obe complains that this fails in 9.1, though it worked before:

regression=# CREATE DOMAIN topoelementarray AS integer[];
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:

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

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

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

Comments, better ideas?

regards, tom lane


Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2011-05-24 16:17:28 Re: 9.2 schedule
Previous Message Robert Haas 2011-05-24 15:54:19 Re: 9.2 schedule