lynn@creditlink.com writes:
> 2. The following functions on 9.0.4 but fails on 9.1.3. (Discovered during a
> dump/restore for upgrade).
> 3. Code:
> creditlink=# create domain foo as bigint[];
> CREATE DOMAIN
> creditlink=# create function foobar(variadic foo) as $$ select true $$
> language sql;
> ERROR: 42P13: VARIADIC parameter must be an array
> LOCATION: examine_parameter_list, functioncmds.c:279
I think this is an intentional change caused by this commit:
http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=529cb267a
In general we are now more wary of treating domains-over-arrays as being
exactly equivalent to their base types. An example of why this is not
mere nit-picking is:
create domain foo3 as bigint[] check(array_length(value,1) = 3);
create function foobar(variadic foo3) ...
If use of this domain, rather than just writing bigint[], is to mean
anything at all, it would have to mean that the function should fail
for less or more than three arguments, no? Which is something the
variadic-function machinery is not prepared to check. So although
making the error message go away would be a one-line change, properly
enabling this feature would require adding the ability to check domain
constraints to places that don't have it today. We might get around to
that someday, but 9.1's never going to have it.
In short, I don't think we're going to change 9.1's behavior here.
Possibly there should be a TODO item to investigate allowing domains as
variadic-function arguments in the future. People would be more likely
to get excited about that if you were to offer a strong use-case why
it's important to not just write bigint[] here.
regards, tom lane
