User could use VARIADIC to specify parameter list when defining UDF
if they want to use variadic parameters. It is easier for user to write
only one variadic function instead of same name function with different
parameters. An example for using variadic:
create function concat(text, variadic anyarray) returns text as $$
select array_to_string($2, $1);
$$ language sql immutable strict;

select concat('%', 1, 2, 3, 4, 5);

NOTE: The variadic change set is ported from upstream of PostgreSQL:
commit 517ae403
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Thu Dec 18 18:20:35 2008 +0000

Code review for function default parameters patch.  Fix numerous problems as
per recent discussions.  In passing this also fixes a couple of bugs in
the previous variadic-parameters patch.

commit 6563e9e2
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Wed Jul 16 16:55:24 2008 +0000

Add a "provariadic" column to pg_proc to eliminate the remarkably expensive
need to deconstruct proargmodes for each pg_proc entry inspected by
FuncnameGetCandidates().  Fixes function lookup performance regression
caused by yesterday's variadic-functions patch.

In passing, make pg_proc.probin be NULL, rather than a dummy value '-',
in cases where it is not actually used for the particular type of function.
This should buy back some of the space cost of the extra column.

commit d89737d3
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Wed Jul 16 01:30:23 2008 +0000

Support "variadic" functions, which can accept a variable number of arguments
so long as all the trailing arguments are of the same (non-array) type.
The function receives them as a single array argument (which is why they
have to all be the same type).

It might be useful to extend this facility to aggregates, but this patch
doesn't do that.

This patch imposes a noticeable slowdown on function lookup --- a follow-on
patch will fix that by adding a redundant column to pg_proc.

Conflicts:
	src/backend/gpopt/gpdbwrappers.cpp