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