1- <!-- $PostgreSQL: pgsql/doc/src/sgml/xfunc.sgml,v 1.130 2007/11/10 20:14:36 tgl Exp $ -->
1+ <!-- $PostgreSQL: pgsql/doc/src/sgml/xfunc.sgml,v 1.131 2008/07/16 01:30:21 tgl Exp $ -->
22
33 <sect1 id="xfunc">
44 <title>User-Defined Functions</title>
@@ -495,7 +495,7 @@ SELECT getname(new_emp());
495495 None
496496(1 row)
497497</screen>
498- </para>
498+ </para>
499499
500500 <para>
501501 Still another way to use a function that returns a composite type is to
@@ -505,7 +505,7 @@ SELECT getname(new_emp());
505505 </sect2>
506506
507507 <sect2 id="xfunc-output-parameters">
508- <title>Functions with Output Parameters</title>
508+ <title><acronym>SQL</> Functions with Output Parameters</title>
509509
510510 <indexterm>
511511 <primary>function</primary>
@@ -578,9 +578,75 @@ DROP FUNCTION sum_n_product (int, int);
578578
579579 <para>
580580 Parameters can be marked as <literal>IN</> (the default),
581- <literal>OUT</>, or <literal>INOUT</>. An <literal>INOUT</>
581+ <literal>OUT</>, <literal>INOUT</>, or <literal>VARIADIC</>.
582+ An <literal>INOUT</>
582583 parameter serves as both an input parameter (part of the calling
583584 argument list) and an output parameter (part of the result record type).
585+ <literal>VARIADIC</> parameters are input parameters, but are treated
586+ specially as described next.
587+ </para>
588+ </sect2>
589+
590+ <sect2 id="xfunc-sql-variadic-functions">
591+ <title><acronym>SQL</> Functions with Variable Numbers of Arguments</title>
592+
593+ <indexterm>
594+ <primary>function</primary>
595+ <secondary>variadic</secondary>
596+ </indexterm>
597+
598+ <indexterm>
599+ <primary>variadic function</primary>
600+ </indexterm>
601+
602+ <para>
603+ <acronym>SQL</acronym> functions can be declared to accept
604+ variable numbers of arguments, so long as all the <quote>optional</>
605+ arguments are of the same data type. The optional arguments will be
606+ passed to the function as an array. The function is declared by
607+ marking the last parameter as <literal>VARIADIC</>; this parameter
608+ must be declared as being of an array type. For example:
609+
610+ <screen>
611+ CREATE FUNCTION mleast(VARIADIC numeric[]) RETURNS numeric AS $$
612+ SELECT min($1[i]) FROM generate_subscripts($1, 1) g(i);
613+ $$ LANGUAGE SQL;
614+
615+ SELECT mleast(10, -1, 5, 4.4);
616+ mleast
617+ --------
618+ -1
619+ (1 row)
620+ </screen>
621+
622+ Effectively, all the actual arguments at or beyond the
623+ <literal>VARIADIC</> position are gathered up into a one-dimensional
624+ array, as if you had written
625+
626+ <screen>
627+ SELECT mleast(ARRAY[10, -1, 5, 4.4]); -- doesn't work
628+ </screen>
629+
630+ You can't actually write that, though — or at least, it will
631+ not match this function definition. A parameter marked
632+ <literal>VARIADIC</> matches one or more occurrences of its element
633+ type, not of its own type.
634+ </para>
635+
636+ <para>
637+ Sometimes it is useful to be able to pass an already-constructed array
638+ to a variadic function; this is particularly handy when one variadic
639+ function wants to pass on its array parameter to another one. You can
640+ do that by specifying <literal>VARIADIC</> in the call:
641+
642+ <screen>
643+ SELECT mleast(VARIADIC ARRAY[10, -1, 5, 4.4]);
644+ </screen>
645+
646+ This prevents expansion of the function's variadic parameter into its
647+ element type, thereby allowing the array argument value to match
648+ normally. <literal>VARIADIC</> can only be attached to the last
649+ actual argument of a function call.
584650 </para>
585651 </sect2>
586652
@@ -795,13 +861,45 @@ DETAIL: A function returning a polymorphic type must have at least one polymorp
795861 For example:
796862<screen>
797863CREATE FUNCTION dup (f1 anyelement, OUT f2 anyelement, OUT f3 anyarray)
798- AS 'select $1, array[$1,$1]' LANGUAGEsql ;
864+ AS 'select $1, array[$1,$1]' LANGUAGESQL ;
799865
800866SELECT * FROM dup(22);
801867 f2 | f3
802868----+---------
803869 22 | {22,22}
804870(1 row)
871+ </screen>
872+ </para>
873+
874+ <para>
875+ Polymorphism can also be used with variadic functions.
876+ For example:
877+ <screen>
878+ CREATE FUNCTION anyleast (VARIADIC anyarray) RETURNS anyelement AS $$
879+ SELECT min($1[i]) FROM generate_subscripts($1, 1) g(i);
880+ $$ LANGUAGE SQL;
881+
882+ SELECT anyleast(10, -1, 5, 4);
883+ anyleast
884+ ----------
885+ -1
886+ (1 row)
887+
888+ SELECT anyleast('abc'::text, 'def');
889+ anyleast
890+ ----------
891+ abc
892+ (1 row)
893+
894+ CREATE FUNCTION concat(text, VARIADIC anyarray) RETURNS text AS $$
895+ SELECT array_to_string($2, $1);
896+ $$ LANGUAGE SQL;
897+
898+ SELECT concat('|', 1, 4, 2);
899+ concat
900+ --------
901+ 1|4|2
902+ (1 row)
805903</screen>
806904 </para>
807905 </sect2>
@@ -852,6 +950,16 @@ CREATE FUNCTION test(smallint, double precision) RETURNS ...
852950 avoid the problem by not choosing conflicting names.
853951 </para>
854952
953+ <para>
954+ Another possible conflict is between variadic and non-variadic functions.
955+ For instance, it is possible to create both <literal>foo(numeric)</> and
956+ <literal>foo(VARIADIC numeric[])</>. In this case it is unclear which one
957+ should be matched to a call providing a single numeric argument, such as
958+ <literal>foo(10.1)</>. The rule is that the function appearing
959+ earlier in the search path is used, or if the two functions are in the
960+ same schema, the non-variadic one is preferred.
961+ </para>
962+
855963 <para>
856964 When overloading C-language functions, there is an additional
857965 constraint: The C name of each function in the family of
@@ -2952,7 +3060,25 @@ CREATE FUNCTION make_array(anyelement) RETURNS anyarray
29523060 LANGUAGE C IMMUTABLE;
29533061</programlisting>
29543062 </para>
3063+
3064+ <para>
3065+ There is a variant of polymorphism that is only available to C-language
3066+ functions: they can be declared to take parameters of type
3067+ <literal>"any"</>. (Note that this type name must be double-quoted,
3068+ since it's also a SQL reserved word.) This works like
3069+ <type>anyelement</> except that it does not constrain different
3070+ <literal>"any"</> arguments to be the same type, nor do they help
3071+ determine the function's result type. A C-language function can also
3072+ declare its final parameter to be <literal>VARIADIC "any"</>. This will
3073+ match one or more actual arguments of any type (not necessarily the same
3074+ type). These arguments will <emphasis>not</> be gathered into an array
3075+ as happens with normal variadic functions; they will just be passed to
3076+ the function separately. The <function>PG_NARGS()</> macro and the
3077+ methods described above must be used to determine the number of actual
3078+ arguments and their types when using this feature.
3079+ </para>
29553080 </sect2>
3081+
29563082 <sect2>
29573083 <title>Shared Memory and LWLocks</title>
29583084