Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitd89737d

Browse files
committed
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 theyhave to all be the same type).It might be useful to extend this facility to aggregates, but this patchdoesn't do that.This patch imposes a noticeable slowdown on function lookup --- a follow-onpatch will fix that by adding a redundant column to pg_proc.Pavel Stehule
1 parent2c77329 commitd89737d

38 files changed

+915
-170
lines changed

‎doc/src/sgml/catalogs.sgml

Lines changed: 10 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/catalogs.sgml,v 2.168 2008/07/14 00:51:45 tgl Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/catalogs.sgml,v 2.169 2008/07/16 01:30:21 tgl Exp $ -->
22
<!--
33
Documentation of the system catalogs, directed toward PostgreSQL developers
44
-->
@@ -3643,7 +3643,8 @@
36433643
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
36443644
<entry>
36453645
An array with the data types of the function arguments. This includes
3646-
only input arguments (including <literal>INOUT</literal> arguments), and thus represents
3646+
only input arguments (including <literal>INOUT</literal> and
3647+
<literal>VARIADIC</> arguments), and thus represents
36473648
the call signature of the function
36483649
</entry>
36493650
</row>
@@ -3654,8 +3655,9 @@
36543655
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
36553656
<entry>
36563657
An array with the data types of the function arguments. This includes
3657-
all arguments (including <literal>OUT</literal> and <literal>INOUT</literal> arguments); however, if all the
3658-
arguments are IN arguments, this field will be null.
3658+
all arguments (including <literal>OUT</literal> and
3659+
<literal>INOUT</literal> arguments); however, if all the
3660+
arguments are <literal>IN</literal> arguments, this field will be null.
36593661
Note that subscripting is 1-based, whereas for historical reasons
36603662
<structfield>proargtypes</> is subscripted from 0
36613663
</entry>
@@ -3669,8 +3671,10 @@
36693671
An array with the modes of the function arguments, encoded as
36703672
<literal>i</literal> for <literal>IN</> arguments,
36713673
<literal>o</literal> for <literal>OUT</> arguments,
3672-
<literal>b</literal> for <literal>INOUT</> arguments.
3673-
If all the arguments are <literal>IN</literal> arguments, this field will be null.
3674+
<literal>b</literal> for <literal>INOUT</> arguments,
3675+
<literal>v</literal> for <literal>VARIADIC</> arguments.
3676+
If all the arguments are <literal>IN</literal> arguments,
3677+
this field will be null.
36743678
Note that subscripts correspond to positions of
36753679
<structfield>proallargtypes</> not <structfield>proargtypes</>
36763680
</entry>

‎doc/src/sgml/extend.sgml

Lines changed: 11 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/extend.sgml,v 1.36 2007/08/31 21:33:48 momjian Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/extend.sgml,v 1.37 2008/07/16 01:30:21 tgl Exp $ -->
22

33
<chapter id="extend">
44
<title>Extending <acronym>SQL</acronym></title>
@@ -254,6 +254,16 @@
254254
is equivalent to declaring it as <literal>f(anyenum, anyenum)</>:
255255
both actual arguments have to be the same enum type.
256256
</para>
257+
258+
<para>
259+
A variadic function (one taking a variable number of arguments, as in
260+
<xref linkend="xfunc-sql-variadic-functions">) can be
261+
polymorphic: this is accomplished by declaring its last parameter as
262+
<literal>VARIADIC</> <type>anyarray</>. For purposes of argument
263+
matching and determining the actual result type, such a function behaves
264+
the same as if you had written the appropriate number of
265+
<type>anynonarray</> parameters.
266+
</para>
257267
</sect2>
258268
</sect1>
259269

‎doc/src/sgml/plpgsql.sgml

Lines changed: 8 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.131 2008/06/27 01:52:59 tgl Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.132 2008/07/16 01:30:21 tgl Exp $ -->
22

33
<chapter id="plpgsql">
44
<title><application>PL/pgSQL</application> - <acronym>SQL</acronym> Procedural Language</title>
@@ -121,6 +121,13 @@
121121
calling query, as discussed in <xref linkend="queries-tablefunctions">.
122122
</para>
123123

124+
<para>
125+
<application>PL/pgSQL</> functions can be declared to accept a variable
126+
number of arguments by using the <literal>VARIADIC</> marker. This
127+
works exactly the same way as for SQL functions, as discussed in
128+
<xref linkend="xfunc-sql-variadic-functions">.
129+
</para>
130+
124131
<para>
125132
<application>PL/pgSQL</> functions can also be declared to accept
126133
and return the polymorphic types

‎doc/src/sgml/ref/alter_function.sgml

Lines changed: 6 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
<!--
2-
$PostgreSQL: pgsql/doc/src/sgml/ref/alter_function.sgml,v 1.15 2007/09/03 18:46:29 tgl Exp $
2+
$PostgreSQL: pgsql/doc/src/sgml/ref/alter_function.sgml,v 1.16 2008/07/16 01:30:21 tgl Exp $
33
PostgreSQL documentation
44
-->
55

@@ -81,13 +81,14 @@ where <replaceable class="PARAMETER">action</replaceable> is one of:
8181

8282
<listitem>
8383
<para>
84-
The mode of an argument: either <literal>IN</>, <literal>OUT</>,
85-
or <literal>INOUT</>. If omitted, the default is <literal>IN</>.
84+
The mode of an argument: <literal>IN</>, <literal>OUT</>,
85+
<literal>INOUT</>, or <literal>VARIADIC</>.
86+
If omitted, the default is <literal>IN</>.
8687
Note that <command>ALTER FUNCTION</command> does not actually pay
8788
any attention to <literal>OUT</> arguments, since only the input
8889
arguments are needed to determine the function's identity.
89-
So it is sufficient to list the <literal>IN</> and<literal>INOUT</>
90-
arguments.
90+
So it is sufficient to list the <literal>IN</>,<literal>INOUT</>,
91+
and <literal>VARIADIC</>arguments.
9192
</para>
9293
</listitem>
9394
</varlistentry>

‎doc/src/sgml/ref/comment.sgml

Lines changed: 6 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
<!--
2-
$PostgreSQL: pgsql/doc/src/sgml/ref/comment.sgml,v 1.36 2007/08/21 21:08:47 tgl Exp $
2+
$PostgreSQL: pgsql/doc/src/sgml/ref/comment.sgml,v 1.37 2008/07/16 01:30:21 tgl Exp $
33
PostgreSQL documentation
44
-->
55

@@ -136,13 +136,14 @@ COMMENT ON
136136

137137
<listitem>
138138
<para>
139-
The mode of a function argument: either <literal>IN</>, <literal>OUT</>,
140-
or <literal>INOUT</>. If omitted, the default is <literal>IN</>.
139+
The mode of a function argument: <literal>IN</>, <literal>OUT</>,
140+
<literal>INOUT</>, or <literal>VARIADIC</>.
141+
If omitted, the default is <literal>IN</>.
141142
Note that <command>COMMENT ON FUNCTION</command> does not actually pay
142143
any attention to <literal>OUT</> arguments, since only the input
143144
arguments are needed to determine the function's identity.
144-
So it is sufficient to list the <literal>IN</> and<literal>INOUT</>
145-
arguments.
145+
So it is sufficient to list the <literal>IN</>,<literal>INOUT</>,
146+
and <literal>VARIADIC</>arguments.
146147
</para>
147148
</listitem>
148149
</varlistentry>

‎doc/src/sgml/ref/create_function.sgml

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
<!--
2-
$PostgreSQL: pgsql/doc/src/sgml/ref/create_function.sgml,v 1.78 2007/09/11 00:06:41 tgl Exp $
2+
$PostgreSQL: pgsql/doc/src/sgml/ref/create_function.sgml,v 1.79 2008/07/16 01:30:21 tgl Exp $
33
-->
44

55
<refentry id="SQL-CREATEFUNCTION">
@@ -101,8 +101,9 @@ CREATE [ OR REPLACE ] FUNCTION
101101

102102
<listitem>
103103
<para>
104-
The mode of an argument: either <literal>IN</>, <literal>OUT</>,
105-
or <literal>INOUT</>. If omitted, the default is <literal>IN</>.
104+
The mode of an argument: <literal>IN</>, <literal>OUT</>,
105+
<literal>INOUT</>, or <literal>VARIADIC</>.
106+
If omitted, the default is <literal>IN</>.
106107
</para>
107108
</listitem>
108109
</varlistentry>

‎doc/src/sgml/ref/drop_function.sgml

Lines changed: 6 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
<!--
2-
$PostgreSQL: pgsql/doc/src/sgml/ref/drop_function.sgml,v 1.33 2007/01/31 23:26:03 momjian Exp $
2+
$PostgreSQL: pgsql/doc/src/sgml/ref/drop_function.sgml,v 1.34 2008/07/16 01:30:21 tgl Exp $
33
PostgreSQL documentation
44
-->
55

@@ -65,13 +65,14 @@ DROP FUNCTION [ IF EXISTS ] <replaceable class="parameter">name</replaceable> (
6565

6666
<listitem>
6767
<para>
68-
The mode of an argument: either <literal>IN</>, <literal>OUT</>,
69-
or <literal>INOUT</>. If omitted, the default is <literal>IN</>.
68+
The mode of an argument: <literal>IN</>, <literal>OUT</>,
69+
<literal>INOUT</>, or <literal>VARIADIC</>.
70+
If omitted, the default is <literal>IN</>.
7071
Note that <command>DROP FUNCTION</command> does not actually pay
7172
any attention to <literal>OUT</> arguments, since only the input
7273
arguments are needed to determine the function's identity.
73-
So it is sufficient to list the <literal>IN</> and<literal>INOUT</>
74-
arguments.
74+
So it is sufficient to list the <literal>IN</>,<literal>INOUT</>,
75+
and <literal>VARIADIC</>arguments.
7576
</para>
7677
</listitem>
7778
</varlistentry>

‎doc/src/sgml/typeconv.sgml

Lines changed: 13 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/typeconv.sgml,v 1.54 2008/07/11 07:02:43 petere Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/typeconv.sgml,v 1.55 2008/07/16 01:30:21 tgl Exp $ -->
22

33
<chapter Id="typeconv">
44
<title>Type Conversion</title>
@@ -503,6 +503,18 @@ different argument types are considered on an equal footing regardless of
503503
search path position.
504504
</para>
505505
</step>
506+
<step performance="optional">
507+
<para>
508+
If a function is declared with a <literal>VARIADIC</> array parameter, and
509+
the call does not use the <literal>VARIADIC</> keyword, then the function
510+
is treated as if the array parameter were replaced by one or more occurrences
511+
of its element type, as needed to match the call. After such expansion the
512+
function might have effective argument types identical to some non-variadic
513+
function. In that case the function appearing earlier in the search path is
514+
used, or if the two functions are in the same schema, the non-variadic one is
515+
selected.
516+
</para>
517+
</step>
506518
</substeps>
507519
</step>
508520

‎doc/src/sgml/xfunc.sgml

Lines changed: 131 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
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 &mdash; 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>
797863
CREATE 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

800866
SELECT * 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

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp