Baoding-FenShuaJiang
/
Green_GoodERP18_FSJ_Standard
Watch 1
Star 0
Wiki 捐赠
gooderp18绿色标准版
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Tree: 0f75e31513
Branches Tags
${ item.name }
Create branch ${ searchTerm }
from '0f75e31513'
${ noResults }
Green_GoodERP18_FSJ_Standard/PostgreSQL/doc/postgresql/html/xfunc-sql.html

1052 lines
50KB
Raw Blame History 

  1. <?xml version="1.0" encoding="UTF-8" standalone="no"?>

  2. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>37.5. Query Language (SQL) Functions</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets V1.79.1" /><link rel="prev" href="xproc.html" title="37.4. User-Defined Procedures" /><link rel="next" href="xfunc-overload.html" title="37.6. Function Overloading" /></head><body><div xmlns="http://www.w3.org/TR/xhtml1/transitional" class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">37.5. Query Language (<acronym xmlns="http://www.w3.org/1999/xhtml" class="acronym">SQL</acronym>) Functions</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="xproc.html" title="37.4. User-Defined Procedures">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="extend.html" title="Chapter 37. Extending SQL">Up</a></td><th width="60%" align="center">Chapter 37. Extending <acronym xmlns="http://www.w3.org/1999/xhtml" class="acronym">SQL</acronym></th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 12.4 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="xfunc-overload.html" title="37.6. Function Overloading">Next</a></td></tr></table><hr></hr></div><div class="sect1" id="XFUNC-SQL"><div class="titlepage"><div><div><h2 class="title" style="clear: both">37.5. Query Language (<acronym class="acronym">SQL</acronym>) Functions</h2></div></div></div><div class="toc"><dl class="toc"><dt><span class="sect2"><a href="xfunc-sql.html#XFUNC-SQL-FUNCTION-ARGUMENTS">37.5.1. Arguments for <acronym class="acronym">SQL</acronym> Functions</a></span></dt><dt><span class="sect2"><a href="xfunc-sql.html#XFUNC-SQL-BASE-FUNCTIONS">37.5.2. <acronym class="acronym">SQL</acronym> Functions on Base Types</a></span></dt><dt><span class="sect2"><a href="xfunc-sql.html#XFUNC-SQL-COMPOSITE-FUNCTIONS">37.5.3. <acronym class="acronym">SQL</acronym> Functions on Composite Types</a></span></dt><dt><span class="sect2"><a href="xfunc-sql.html#XFUNC-OUTPUT-PARAMETERS">37.5.4. <acronym class="acronym">SQL</acronym> Functions with Output Parameters</a></span></dt><dt><span class="sect2"><a href="xfunc-sql.html#XFUNC-SQL-VARIADIC-FUNCTIONS">37.5.5. <acronym class="acronym">SQL</acronym> Functions with Variable Numbers of Arguments</a></span></dt><dt><span class="sect2"><a href="xfunc-sql.html#XFUNC-SQL-PARAMETER-DEFAULTS">37.5.6. <acronym class="acronym">SQL</acronym> Functions with Default Values for Arguments</a></span></dt><dt><span class="sect2"><a href="xfunc-sql.html#XFUNC-SQL-TABLE-FUNCTIONS">37.5.7. <acronym class="acronym">SQL</acronym> Functions as Table Sources</a></span></dt><dt><span class="sect2"><a href="xfunc-sql.html#XFUNC-SQL-FUNCTIONS-RETURNING-SET">37.5.8. <acronym class="acronym">SQL</acronym> Functions Returning Sets</a></span></dt><dt><span class="sect2"><a href="xfunc-sql.html#XFUNC-SQL-FUNCTIONS-RETURNING-TABLE">37.5.9. <acronym class="acronym">SQL</acronym> Functions Returning <code class="literal">TABLE</code></a></span></dt><dt><span class="sect2"><a href="xfunc-sql.html#id-1.8.3.8.18">37.5.10. Polymorphic <acronym class="acronym">SQL</acronym> Functions</a></span></dt><dt><span class="sect2"><a href="xfunc-sql.html#id-1.8.3.8.19">37.5.11. <acronym class="acronym">SQL</acronym> Functions with Collations</a></span></dt></dl></div><a id="id-1.8.3.8.2" class="indexterm"></a><p>

  3.     SQL functions execute an arbitrary list of SQL statements, returning

  4.     the result of the last query in the list.

  5.     In the simple (non-set)

  6.     case, the first row of the last query's result will be returned.

  7.     (Bear in mind that <span class="quote">“<span class="quote">the first row</span>”</span> of a multirow

  8.     result is not well-defined unless you use <code class="literal">ORDER BY</code>.)

  9.     If the last query happens

  10.     to return no rows at all, the null value will be returned.

  11.    </p><p>

  12.     Alternatively, an SQL function can be declared to return a set (that is,

  13.     multiple rows) by specifying the function's return type as <code class="literal">SETOF

  14.     <em class="replaceable"><code>sometype</code></em></code>, or equivalently by declaring it as

  15.     <code class="literal">RETURNS TABLE(<em class="replaceable"><code>columns</code></em>)</code>.  In this case

  16.     all rows of the last query's result are returned.  Further details appear

  17.     below.

  18.    </p><p>

  19.     The body of an SQL function must be a list of SQL

  20.     statements separated by semicolons.  A semicolon after the last

  21.     statement is optional.  Unless the function is declared to return

  22.     <code class="type">void</code>, the last statement must be a <code class="command">SELECT</code>,

  23.     or an <code class="command">INSERT</code>, <code class="command">UPDATE</code>, or <code class="command">DELETE</code>

  24.     that has a <code class="literal">RETURNING</code> clause.

  25.    </p><p>

  26.      Any collection of commands in the  <acronym class="acronym">SQL</acronym>

  27.      language can be packaged together and defined as a function.

  28.      Besides <code class="command">SELECT</code> queries, the commands can include data

  29.      modification queries (<code class="command">INSERT</code>,

  30.      <code class="command">UPDATE</code>, and <code class="command">DELETE</code>), as well as

  31.      other SQL commands. (You cannot use transaction control commands, e.g.

  32.      <code class="command">COMMIT</code>, <code class="command">SAVEPOINT</code>, and some utility

  33.      commands, e.g.  <code class="literal">VACUUM</code>, in <acronym class="acronym">SQL</acronym> functions.)

  34.      However, the final command

  35.      must be a <code class="command">SELECT</code> or have a <code class="literal">RETURNING</code>

  36.      clause that returns whatever is

  37.      specified as the function's return type.  Alternatively, if you

  38.      want to define a SQL function that performs actions but has no

  39.      useful value to return, you can define it as returning <code class="type">void</code>.

  40.      For example, this function removes rows with negative salaries from

  41.      the <code class="literal">emp</code> table:

  42. 

  43. </p><pre class="screen">

  44. CREATE FUNCTION clean_emp() RETURNS void AS '

  45.     DELETE FROM emp

  46.         WHERE salary &lt; 0;

  47. ' LANGUAGE SQL;

  48. 

  49. SELECT clean_emp();

  50. 

  51.  clean_emp

  52. -----------

  53. 

  54. (1 row)

  55. </pre><p>

  56.     </p><div class="note"><h3 class="title">Note</h3><p>

  57.       The entire body of a SQL function is parsed before any of it is

  58.       executed.  While a SQL function can contain commands that alter

  59.       the system catalogs (e.g., <code class="command">CREATE TABLE</code>), the effects

  60.       of such commands will not be visible during parse analysis of

  61.       later commands in the function.  Thus, for example,

  62.       <code class="literal">CREATE TABLE foo (...); INSERT INTO foo VALUES(...);</code>

  63.       will not work as desired if packaged up into a single SQL function,

  64.       since <code class="structname">foo</code> won't exist yet when the <code class="command">INSERT</code>

  65.       command is parsed.  It's recommended to use <span class="application">PL/pgSQL</span>

  66.       instead of a SQL function in this type of situation.

  67.      </p></div><p>

  68.     The syntax of the <code class="command">CREATE FUNCTION</code> command requires

  69.     the function body to be written as a string constant.  It is usually

  70.     most convenient to use dollar quoting (see <a class="xref" href="sql-syntax-lexical.html#SQL-SYNTAX-DOLLAR-QUOTING" title="4.1.2.4. Dollar-Quoted String Constants">Section 4.1.2.4</a>) for the string constant.

  71.     If you choose to use regular single-quoted string constant syntax,

  72.     you must double single quote marks (<code class="literal">'</code>) and backslashes

  73.     (<code class="literal">\</code>) (assuming escape string syntax) in the body of

  74.     the function (see <a class="xref" href="sql-syntax-lexical.html#SQL-SYNTAX-STRINGS" title="4.1.2.1. String Constants">Section 4.1.2.1</a>).

  75.    </p><div class="sect2" id="XFUNC-SQL-FUNCTION-ARGUMENTS"><div class="titlepage"><div><div><h3 class="title">37.5.1. Arguments for <acronym class="acronym">SQL</acronym> Functions</h3></div></div></div><a id="id-1.8.3.8.9.2" class="indexterm"></a><p>

  76.      Arguments of a SQL function can be referenced in the function

  77.      body using either names or numbers.  Examples of both methods appear

  78.      below.

  79.     </p><p>

  80.      To use a name, declare the function argument as having a name, and

  81.      then just write that name in the function body.  If the argument name

  82.      is the same as any column name in the current SQL command within the

  83.      function, the column name will take precedence.  To override this,

  84.      qualify the argument name with the name of the function itself, that is

  85.      <code class="literal"><em class="replaceable"><code>function_name</code></em>.<em class="replaceable"><code>argument_name</code></em></code>.

  86.      (If this would conflict with a qualified column name, again the column

  87.      name wins.  You can avoid the ambiguity by choosing a different alias for

  88.      the table within the SQL command.)

  89.     </p><p>

  90.      In the older numeric approach, arguments are referenced using the syntax

  91.      <code class="literal">$<em class="replaceable"><code>n</code></em></code>: <code class="literal">$1</code> refers to the first input

  92.      argument, <code class="literal">$2</code> to the second, and so on.  This will work

  93.      whether or not the particular argument was declared with a name.

  94.     </p><p>

  95.      If an argument is of a composite type, then the dot notation,

  96.      e.g., <code class="literal"><em class="replaceable"><code>argname</code></em>.<em class="replaceable"><code>fieldname</code></em></code> or

  97.      <code class="literal">$1.<em class="replaceable"><code>fieldname</code></em></code>, can be used to access attributes of the

  98.      argument.  Again, you might need to qualify the argument's name with the

  99.      function name to make the form with an argument name unambiguous.

  100.     </p><p>

  101.      SQL function arguments can only be used as data values,

  102.      not as identifiers.  Thus for example this is reasonable:

  103. </p><pre class="programlisting">

  104. INSERT INTO mytable VALUES ($1);

  105. </pre><p>

  106. but this will not work:

  107. </p><pre class="programlisting">

  108. INSERT INTO $1 VALUES (42);

  109. </pre><p>

  110.     </p><div class="note"><h3 class="title">Note</h3><p>

  111.       The ability to use names to reference SQL function arguments was added

  112.       in <span class="productname">PostgreSQL</span> 9.2.  Functions to be used in

  113.       older servers must use the <code class="literal">$<em class="replaceable"><code>n</code></em></code> notation.

  114.      </p></div></div><div class="sect2" id="XFUNC-SQL-BASE-FUNCTIONS"><div class="titlepage"><div><div><h3 class="title">37.5.2. <acronym class="acronym">SQL</acronym> Functions on Base Types</h3></div></div></div><p>

  115.      The simplest possible <acronym class="acronym">SQL</acronym> function has no arguments and

  116.      simply returns a base type, such as <code class="type">integer</code>:

  117. 

  118. </p><pre class="screen">

  119. CREATE FUNCTION one() RETURNS integer AS $$

  120.     SELECT 1 AS result;

  121. $$ LANGUAGE SQL;

  122. 

  123. -- Alternative syntax for string literal:

  124. CREATE FUNCTION one() RETURNS integer AS '

  125.     SELECT 1 AS result;

  126. ' LANGUAGE SQL;

  127. 

  128. SELECT one();

  129. 

  130.  one

  131. -----

  132.    1

  133. </pre><p>

  134.     </p><p>

  135.      Notice that we defined a column alias within the function body for the result of the function

  136.      (with  the  name <code class="literal">result</code>),  but this column alias is not visible

  137.      outside the function.  Hence,  the  result  is labeled <code class="literal">one</code>

  138.      instead of <code class="literal">result</code>.

  139.     </p><p>

  140.      It is almost as easy to define <acronym class="acronym">SQL</acronym> functions

  141.      that take base types as arguments:

  142. 

  143. </p><pre class="screen">

  144. CREATE FUNCTION add_em(x integer, y integer) RETURNS integer AS $$

  145.     SELECT x + y;

  146. $$ LANGUAGE SQL;

  147. 

  148. SELECT add_em(1, 2) AS answer;

  149. 

  150.  answer

  151. --------

  152.       3

  153. </pre><p>

  154.     </p><p>

  155.      Alternatively, we could dispense with names for the arguments and

  156.      use numbers:

  157. 

  158. </p><pre class="screen">

  159. CREATE FUNCTION add_em(integer, integer) RETURNS integer AS $$

  160.     SELECT $1 + $2;

  161. $$ LANGUAGE SQL;

  162. 

  163. SELECT add_em(1, 2) AS answer;

  164. 

  165.  answer

  166. --------

  167.       3

  168. </pre><p>

  169.     </p><p>

  170.      Here is a more useful function, which might be used to debit a

  171.      bank account:

  172. 

  173. </p><pre class="programlisting">

  174. CREATE FUNCTION tf1 (accountno integer, debit numeric) RETURNS numeric AS $$

  175.     UPDATE bank

  176.         SET balance = balance - debit

  177.         WHERE accountno = tf1.accountno;

  178.     SELECT 1;

  179. $$ LANGUAGE SQL;

  180. </pre><p>

  181. 

  182.      A user could execute this function to debit account 17 by $100.00 as

  183.      follows:

  184. 

  185. </p><pre class="programlisting">

  186. SELECT tf1(17, 100.0);

  187. </pre><p>

  188.     </p><p>

  189.      In this example, we chose the name <code class="literal">accountno</code> for the first

  190.      argument, but this is the same as the name of a column in the

  191.      <code class="literal">bank</code> table.  Within the <code class="command">UPDATE</code> command,

  192.      <code class="literal">accountno</code> refers to the column <code class="literal">bank.accountno</code>,

  193.      so <code class="literal">tf1.accountno</code> must be used to refer to the argument.

  194.      We could of course avoid this by using a different name for the argument.

  195.     </p><p>

  196.      In practice one would probably like a more useful result from the

  197.      function than a constant 1, so a more likely definition

  198.      is:

  199. 

  200. </p><pre class="programlisting">

  201. CREATE FUNCTION tf1 (accountno integer, debit numeric) RETURNS numeric AS $$

  202.     UPDATE bank

  203.         SET balance = balance - debit

  204.         WHERE accountno = tf1.accountno;

  205.     SELECT balance FROM bank WHERE accountno = tf1.accountno;

  206. $$ LANGUAGE SQL;

  207. </pre><p>

  208. 

  209.      which adjusts the balance and returns the new balance.

  210.      The same thing could be done in one command using <code class="literal">RETURNING</code>:

  211. 

  212. </p><pre class="programlisting">

  213. CREATE FUNCTION tf1 (accountno integer, debit numeric) RETURNS numeric AS $$

  214.     UPDATE bank

  215.         SET balance = balance - debit

  216.         WHERE accountno = tf1.accountno

  217.     RETURNING balance;

  218. $$ LANGUAGE SQL;

  219. </pre><p>

  220.     </p><p>

  221.      A <acronym class="acronym">SQL</acronym> function must return exactly its declared

  222.      result type.  This may require inserting an explicit cast.

  223.      For example, suppose we wanted the

  224.      previous <code class="function">add_em</code> function to return

  225.      type <code class="type">float8</code> instead.  This won't work:

  226. 

  227. </p><pre class="programlisting">

  228. CREATE FUNCTION add_em(integer, integer) RETURNS float8 AS $$

  229.     SELECT $1 + $2;

  230. $$ LANGUAGE SQL;

  231. </pre><p>

  232. 

  233.      even though in other contexts <span class="productname">PostgreSQL</span>

  234.      would be willing to insert an implicit cast to

  235.      convert <code class="type">integer</code> to <code class="type">float8</code>.

  236.      We need to write it as

  237. 

  238. </p><pre class="programlisting">

  239. CREATE FUNCTION add_em(integer, integer) RETURNS float8 AS $$

  240.     SELECT ($1 + $2)::float8;

  241. $$ LANGUAGE SQL;

  242. </pre><p>

  243.     </p></div><div class="sect2" id="XFUNC-SQL-COMPOSITE-FUNCTIONS"><div class="titlepage"><div><div><h3 class="title">37.5.3. <acronym class="acronym">SQL</acronym> Functions on Composite Types</h3></div></div></div><p>

  244.      When writing functions with arguments of composite types, we must not

  245.      only specify which argument we want but also the desired attribute

  246.      (field) of that argument.  For example, suppose that

  247.      <code class="type">emp</code> is a table containing employee data, and therefore

  248.      also the name of the composite type of each row of the table.  Here

  249.      is a function <code class="function">double_salary</code> that computes what someone's

  250.      salary would be if it were doubled:

  251. 

  252. </p><pre class="screen">

  253. CREATE TABLE emp (

  254.     name        text,

  255.     salary      numeric,

  256.     age         integer,

  257.     cubicle     point

  258. );

  259. 

  260. INSERT INTO emp VALUES ('Bill', 4200, 45, '(2,1)');

  261. 

  262. CREATE FUNCTION double_salary(emp) RETURNS numeric AS $$

  263.     SELECT $1.salary * 2 AS salary;

  264. $$ LANGUAGE SQL;

  265. 

  266. SELECT name, double_salary(emp.*) AS dream

  267.     FROM emp

  268.     WHERE emp.cubicle ~= point '(2,1)';

  269. 

  270.  name | dream

  271. ------+-------

  272.  Bill |  8400

  273. </pre><p>

  274.     </p><p>

  275.      Notice the use of the syntax <code class="literal">$1.salary</code>

  276.      to select one field of the argument row value.  Also notice

  277.      how the calling <code class="command">SELECT</code> command

  278.      uses <em class="replaceable"><code>table_name</code></em><code class="literal">.*</code> to select

  279.      the entire current row of a table as a composite value.  The table

  280.      row can alternatively be referenced using just the table name,

  281.      like this:

  282. </p><pre class="screen">

  283. SELECT name, double_salary(emp) AS dream

  284.     FROM emp

  285.     WHERE emp.cubicle ~= point '(2,1)';

  286. </pre><p>

  287.      but this usage is deprecated since it's easy to get confused.

  288.      (See <a class="xref" href="rowtypes.html#ROWTYPES-USAGE" title="8.16.5. Using Composite Types in Queries">Section 8.16.5</a> for details about these

  289.      two notations for the composite value of a table row.)

  290.     </p><p>

  291.      Sometimes it is handy to construct a composite argument value

  292.      on-the-fly.  This can be done with the <code class="literal">ROW</code> construct.

  293.      For example, we could adjust the data being passed to the function:

  294. </p><pre class="screen">

  295. SELECT name, double_salary(ROW(name, salary*1.1, age, cubicle)) AS dream

  296.     FROM emp;

  297. </pre><p>

  298.     </p><p>

  299.      It is also possible to build a function that returns a composite type.

  300.      This is an example of a function

  301.      that returns a single <code class="type">emp</code> row:

  302. 

  303. </p><pre class="programlisting">

  304. CREATE FUNCTION new_emp() RETURNS emp AS $$

  305.     SELECT text 'None' AS name,

  306.         1000.0 AS salary,

  307.         25 AS age,

  308.         point '(2,2)' AS cubicle;

  309. $$ LANGUAGE SQL;

  310. </pre><p>

  311. 

  312.      In this example we have specified each of  the  attributes

  313.      with  a  constant value, but any computation

  314.      could have been substituted for these constants.

  315.     </p><p>

  316.      Note two important things about defining the function:

  317. 

  318.      </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>

  319.         The select list order in the query must be exactly the same as

  320.         that in which the columns appear in the table associated

  321.         with the composite type.  (Naming the columns, as we did above,

  322.         is irrelevant to the system.)

  323.        </p></li><li class="listitem"><p>

  324.         We must ensure each expression's type matches the corresponding

  325.         column of the composite type, inserting a cast if necessary.

  326.         Otherwise we'll get errors like this:

  327. </p><pre class="screen">

  328. <code class="computeroutput">

  329. ERROR:  function declared to return emp returns varchar instead of text at column 1

  330. </code>

  331. </pre><p>

  332.         As with the base-type case, the function will not insert any casts

  333.         automatically.

  334.        </p></li></ul></div><p>

  335.     </p><p>

  336.      A different way to define the same function is:

  337. 

  338. </p><pre class="programlisting">

  339. CREATE FUNCTION new_emp() RETURNS emp AS $$

  340.     SELECT ROW('None', 1000.0, 25, '(2,2)')::emp;

  341. $$ LANGUAGE SQL;

  342. </pre><p>

  343. 

  344.      Here we wrote a <code class="command">SELECT</code> that returns just a single

  345.      column of the correct composite type.  This isn't really better

  346.      in this situation, but it is a handy alternative in some cases

  347.      — for example, if we need to compute the result by calling

  348.      another function that returns the desired composite value.

  349.      Another example is that if we are trying to write a function that

  350.      returns a domain over composite, rather than a plain composite type,

  351.      it is always necessary to write it as returning a single column,

  352.      since there is no other way to produce a value that is exactly of

  353.      the domain type.

  354.     </p><p>

  355.      We could call this function directly either by using it in

  356.      a value expression:

  357. 

  358. </p><pre class="screen">

  359. SELECT new_emp();

  360. 

  361.          new_emp

  362. --------------------------

  363.  (None,1000.0,25,"(2,2)")

  364. </pre><p>

  365. 

  366.      or by calling it as a table function:

  367. 

  368. </p><pre class="screen">

  369. SELECT * FROM new_emp();

  370. 

  371.  name | salary | age | cubicle

  372. ------+--------+-----+---------

  373.  None | 1000.0 |  25 | (2,2)

  374. </pre><p>

  375. 

  376.      The second way is described more fully in <a class="xref" href="xfunc-sql.html#XFUNC-SQL-TABLE-FUNCTIONS" title="37.5.7. SQL Functions as Table Sources">Section 37.5.7</a>.

  377.     </p><p>

  378.      When you use a function that returns a composite type,

  379.      you might want only one field (attribute) from its result.

  380.      You can do that with syntax like this:

  381. 

  382. </p><pre class="screen">

  383. SELECT (new_emp()).name;

  384. 

  385.  name

  386. ------

  387.  None

  388. </pre><p>

  389. 

  390.      The extra parentheses are needed to keep the parser from getting

  391.      confused.  If you try to do it without them, you get something like this:

  392. 

  393. </p><pre class="screen">

  394. SELECT new_emp().name;

  395. ERROR:  syntax error at or near "."

  396. LINE 1: SELECT new_emp().name;

  397.                         ^

  398. </pre><p>

  399.     </p><p>

  400.      Another option is to use functional notation for extracting an attribute:

  401. 

  402. </p><pre class="screen">

  403. SELECT name(new_emp());

  404. 

  405.  name

  406. ------

  407.  None

  408. </pre><p>

  409. 

  410.      As explained in <a class="xref" href="rowtypes.html#ROWTYPES-USAGE" title="8.16.5. Using Composite Types in Queries">Section 8.16.5</a>, the field notation and

  411.      functional notation are equivalent.

  412.     </p><p>

  413.      Another way to use a function returning a composite type is to pass the

  414.      result to another function that accepts the correct row type as input:

  415. 

  416. </p><pre class="screen">

  417. CREATE FUNCTION getname(emp) RETURNS text AS $$

  418.     SELECT $1.name;

  419. $$ LANGUAGE SQL;

  420. 

  421. SELECT getname(new_emp());

  422.  getname

  423. ---------

  424.  None

  425. (1 row)

  426. </pre><p>

  427.     </p></div><div class="sect2" id="XFUNC-OUTPUT-PARAMETERS"><div class="titlepage"><div><div><h3 class="title">37.5.4. <acronym class="acronym">SQL</acronym> Functions with Output Parameters</h3></div></div></div><a id="id-1.8.3.8.12.2" class="indexterm"></a><p>

  428.      An alternative way of describing a function's results is to define it

  429.      with <em class="firstterm">output parameters</em>, as in this example:

  430. 

  431. </p><pre class="screen">

  432. CREATE FUNCTION add_em (IN x int, IN y int, OUT sum int)

  433. AS 'SELECT x + y'

  434. LANGUAGE SQL;

  435. 

  436. SELECT add_em(3,7);

  437.  add_em

  438. --------

  439.      10

  440. (1 row)

  441. </pre><p>

  442. 

  443.      This is not essentially different from the version of <code class="literal">add_em</code>

  444.      shown in <a class="xref" href="xfunc-sql.html#XFUNC-SQL-BASE-FUNCTIONS" title="37.5.2. SQL Functions on Base Types">Section 37.5.2</a>.  The real value of

  445.      output parameters is that they provide a convenient way of defining

  446.      functions that return several columns.  For example,

  447. 

  448. </p><pre class="screen">

  449. CREATE FUNCTION sum_n_product (x int, y int, OUT sum int, OUT product int)

  450. AS 'SELECT x + y, x * y'

  451. LANGUAGE SQL;

  452. 

  453.  SELECT * FROM sum_n_product(11,42);

  454.  sum | product

  455. -----+---------

  456.   53 |     462

  457. (1 row)

  458. </pre><p>

  459. 

  460.      What has essentially happened here is that we have created an anonymous

  461.      composite type for the result of the function.  The above example has

  462.      the same end result as

  463. 

  464. </p><pre class="screen">

  465. CREATE TYPE sum_prod AS (sum int, product int);

  466. 

  467. CREATE FUNCTION sum_n_product (int, int) RETURNS sum_prod

  468. AS 'SELECT $1 + $2, $1 * $2'

  469. LANGUAGE SQL;

  470. </pre><p>

  471. 

  472.      but not having to bother with the separate composite type definition

  473.      is often handy.  Notice that the names attached to the output parameters

  474.      are not just decoration, but determine the column names of the anonymous

  475.      composite type.  (If you omit a name for an output parameter, the

  476.      system will choose a name on its own.)

  477.     </p><p>

  478.      Notice that output parameters are not included in the calling argument

  479.      list when invoking such a function from SQL.  This is because

  480.      <span class="productname">PostgreSQL</span> considers only the input

  481.      parameters to define the function's calling signature.  That means

  482.      also that only the input parameters matter when referencing the function

  483.      for purposes such as dropping it.  We could drop the above function

  484.      with either of

  485. 

  486. </p><pre class="screen">

  487. DROP FUNCTION sum_n_product (x int, y int, OUT sum int, OUT product int);

  488. DROP FUNCTION sum_n_product (int, int);

  489. </pre><p>

  490.     </p><p>

  491.      Parameters can be marked as <code class="literal">IN</code> (the default),

  492.      <code class="literal">OUT</code>, <code class="literal">INOUT</code>, or <code class="literal">VARIADIC</code>.

  493.      An <code class="literal">INOUT</code>

  494.      parameter serves as both an input parameter (part of the calling

  495.      argument list) and an output parameter (part of the result record type).

  496.      <code class="literal">VARIADIC</code> parameters are input parameters, but are treated

  497.      specially as described next.

  498.     </p></div><div class="sect2" id="XFUNC-SQL-VARIADIC-FUNCTIONS"><div class="titlepage"><div><div><h3 class="title">37.5.5. <acronym class="acronym">SQL</acronym> Functions with Variable Numbers of Arguments</h3></div></div></div><a id="id-1.8.3.8.13.2" class="indexterm"></a><a id="id-1.8.3.8.13.3" class="indexterm"></a><p>

  499.      <acronym class="acronym">SQL</acronym> functions can be declared to accept

  500.      variable numbers of arguments, so long as all the <span class="quote">“<span class="quote">optional</span>”</span>

  501.      arguments are of the same data type.  The optional arguments will be

  502.      passed to the function as an array.  The function is declared by

  503.      marking the last parameter as <code class="literal">VARIADIC</code>; this parameter

  504.      must be declared as being of an array type.  For example:

  505. 

  506. </p><pre class="screen">

  507. CREATE FUNCTION mleast(VARIADIC arr numeric[]) RETURNS numeric AS $$

  508.     SELECT min($1[i]) FROM generate_subscripts($1, 1) g(i);

  509. $$ LANGUAGE SQL;

  510. 

  511. SELECT mleast(10, -1, 5, 4.4);

  512.  mleast 

  513. --------

  514.      -1

  515. (1 row)

  516. </pre><p>

  517. 

  518.      Effectively, all the actual arguments at or beyond the

  519.      <code class="literal">VARIADIC</code> position are gathered up into a one-dimensional

  520.      array, as if you had written

  521. 

  522. </p><pre class="screen">

  523. SELECT mleast(ARRAY[10, -1, 5, 4.4]);    -- doesn't work

  524. </pre><p>

  525. 

  526.      You can't actually write that, though — or at least, it will

  527.      not match this function definition.  A parameter marked

  528.      <code class="literal">VARIADIC</code> matches one or more occurrences of its element

  529.      type, not of its own type.

  530.     </p><p>

  531.      Sometimes it is useful to be able to pass an already-constructed array

  532.      to a variadic function; this is particularly handy when one variadic

  533.      function wants to pass on its array parameter to another one.  Also,

  534.      this is the only secure way to call a variadic function found in a schema

  535.      that permits untrusted users to create objects; see

  536.      <a class="xref" href="typeconv-func.html" title="10.3. Functions">Section 10.3</a>.  You can do this by

  537.      specifying <code class="literal">VARIADIC</code> in the call:

  538. 

  539. </p><pre class="screen">

  540. SELECT mleast(VARIADIC ARRAY[10, -1, 5, 4.4]);

  541. </pre><p>

  542. 

  543.      This prevents expansion of the function's variadic parameter into its

  544.      element type, thereby allowing the array argument value to match

  545.      normally.  <code class="literal">VARIADIC</code> can only be attached to the last

  546.      actual argument of a function call.

  547.     </p><p>

  548.      Specifying <code class="literal">VARIADIC</code> in the call is also the only way to

  549.      pass an empty array to a variadic function, for example:

  550. 

  551. </p><pre class="screen">

  552. SELECT mleast(VARIADIC ARRAY[]::numeric[]);

  553. </pre><p>

  554. 

  555.      Simply writing <code class="literal">SELECT mleast()</code> does not work because a

  556.      variadic parameter must match at least one actual argument.

  557.      (You could define a second function also named <code class="literal">mleast</code>,

  558.      with no parameters, if you wanted to allow such calls.)

  559.     </p><p>

  560.      The array element parameters generated from a variadic parameter are

  561.      treated as not having any names of their own.  This means it is not

  562.      possible to call a variadic function using named arguments (<a class="xref" href="sql-syntax-calling-funcs.html" title="4.3. Calling Functions">Section 4.3</a>), except when you specify

  563.      <code class="literal">VARIADIC</code>.  For example, this will work:

  564. 

  565. </p><pre class="screen">

  566. SELECT mleast(VARIADIC arr =&gt; ARRAY[10, -1, 5, 4.4]);

  567. </pre><p>

  568. 

  569.      but not these:

  570. 

  571. </p><pre class="screen">

  572. SELECT mleast(arr =&gt; 10);

  573. SELECT mleast(arr =&gt; ARRAY[10, -1, 5, 4.4]);

  574. </pre><p>

  575.     </p></div><div class="sect2" id="XFUNC-SQL-PARAMETER-DEFAULTS"><div class="titlepage"><div><div><h3 class="title">37.5.6. <acronym class="acronym">SQL</acronym> Functions with Default Values for Arguments</h3></div></div></div><a id="id-1.8.3.8.14.2" class="indexterm"></a><p>

  576.      Functions can be declared with default values for some or all input

  577.      arguments.  The default values are inserted whenever the function is

  578.      called with insufficiently many actual arguments.  Since arguments

  579.      can only be omitted from the end of the actual argument list, all

  580.      parameters after a parameter with a default value have to have

  581.      default values as well.  (Although the use of named argument notation

  582.      could allow this restriction to be relaxed, it's still enforced so that

  583.      positional argument notation works sensibly.)  Whether or not you use it,

  584.      this capability creates a need for precautions when calling functions in

  585.      databases where some users mistrust other users; see

  586.      <a class="xref" href="typeconv-func.html" title="10.3. Functions">Section 10.3</a>.

  587.     </p><p>

  588.      For example:

  589. </p><pre class="screen">

  590. CREATE FUNCTION foo(a int, b int DEFAULT 2, c int DEFAULT 3)

  591. RETURNS int

  592. LANGUAGE SQL

  593. AS $$

  594.     SELECT $1 + $2 + $3;

  595. $$;

  596. 

  597. SELECT foo(10, 20, 30);

  598.  foo 

  599. -----

  600.   60

  601. (1 row)

  602. 

  603. SELECT foo(10, 20);

  604.  foo 

  605. -----

  606.   33

  607. (1 row)

  608. 

  609. SELECT foo(10);

  610.  foo 

  611. -----

  612.   15

  613. (1 row)

  614. 

  615. SELECT foo();  -- fails since there is no default for the first argument

  616. ERROR:  function foo() does not exist

  617. </pre><p>

  618.      The <code class="literal">=</code> sign can also be used in place of the

  619.      key word <code class="literal">DEFAULT</code>.

  620.     </p></div><div class="sect2" id="XFUNC-SQL-TABLE-FUNCTIONS"><div class="titlepage"><div><div><h3 class="title">37.5.7. <acronym class="acronym">SQL</acronym> Functions as Table Sources</h3></div></div></div><p>

  621.      All SQL functions can be used in the <code class="literal">FROM</code> clause of a query,

  622.      but it is particularly useful for functions returning composite types.

  623.      If the function is defined to return a base type, the table function

  624.      produces a one-column table.  If the function is defined to return

  625.      a composite type, the table function produces a column for each attribute

  626.      of the composite type.

  627.     </p><p>

  628.      Here is an example:

  629. 

  630. </p><pre class="screen">

  631. CREATE TABLE foo (fooid int, foosubid int, fooname text);

  632. INSERT INTO foo VALUES (1, 1, 'Joe');

  633. INSERT INTO foo VALUES (1, 2, 'Ed');

  634. INSERT INTO foo VALUES (2, 1, 'Mary');

  635. 

  636. CREATE FUNCTION getfoo(int) RETURNS foo AS $$

  637.     SELECT * FROM foo WHERE fooid = $1;

  638. $$ LANGUAGE SQL;

  639. 

  640. SELECT *, upper(fooname) FROM getfoo(1) AS t1;

  641. 

  642.  fooid | foosubid | fooname | upper

  643. -------+----------+---------+-------

  644.      1 |        1 | Joe     | JOE

  645. (1 row)

  646. </pre><p>

  647. 

  648.      As the example shows, we can work with the columns of the function's

  649.      result just the same as if they were columns of a regular table.

  650.     </p><p>

  651.      Note that we only got one row out of the function.  This is because

  652.      we did not use <code class="literal">SETOF</code>.  That is described in the next section.

  653.     </p></div><div class="sect2" id="XFUNC-SQL-FUNCTIONS-RETURNING-SET"><div class="titlepage"><div><div><h3 class="title">37.5.8. <acronym class="acronym">SQL</acronym> Functions Returning Sets</h3></div></div></div><a id="id-1.8.3.8.16.2" class="indexterm"></a><p>

  654.      When an SQL function is declared as returning <code class="literal">SETOF

  655.      <em class="replaceable"><code>sometype</code></em></code>, the function's final

  656.      query is executed to completion, and each row it

  657.      outputs is returned as an element of the result set.

  658.     </p><p>

  659.      This feature is normally used when calling the function in the <code class="literal">FROM</code>

  660.      clause.  In this case each row returned by the function becomes

  661.      a row of the table seen by the query.  For example, assume that

  662.      table <code class="literal">foo</code> has the same contents as above, and we say:

  663. 

  664. </p><pre class="programlisting">

  665. CREATE FUNCTION getfoo(int) RETURNS SETOF foo AS $$

  666.     SELECT * FROM foo WHERE fooid = $1;

  667. $$ LANGUAGE SQL;

  668. 

  669. SELECT * FROM getfoo(1) AS t1;

  670. </pre><p>

  671. 

  672.      Then we would get:

  673. </p><pre class="screen">

  674.  fooid | foosubid | fooname

  675. -------+----------+---------

  676.      1 |        1 | Joe

  677.      1 |        2 | Ed

  678. (2 rows)

  679. </pre><p>

  680.     </p><p>

  681.      It is also possible to return multiple rows with the columns defined by

  682.      output parameters, like this:

  683. 

  684. </p><pre class="programlisting">

  685. CREATE TABLE tab (y int, z int);

  686. INSERT INTO tab VALUES (1, 2), (3, 4), (5, 6), (7, 8);

  687. 

  688. CREATE FUNCTION sum_n_product_with_tab (x int, OUT sum int, OUT product int)

  689. RETURNS SETOF record

  690. AS $$

  691.     SELECT $1 + tab.y, $1 * tab.y FROM tab;

  692. $$ LANGUAGE SQL;

  693. 

  694. SELECT * FROM sum_n_product_with_tab(10);

  695.  sum | product

  696. -----+---------

  697.   11 |      10

  698.   13 |      30

  699.   15 |      50

  700.   17 |      70

  701. (4 rows)

  702. </pre><p>

  703. 

  704.      The key point here is that you must write <code class="literal">RETURNS SETOF record</code>

  705.      to indicate that the function returns multiple rows instead of just one.

  706.      If there is only one output parameter, write that parameter's type

  707.      instead of <code class="type">record</code>.

  708.     </p><p>

  709.      It is frequently useful to construct a query's result by invoking a

  710.      set-returning function multiple times, with the parameters for each

  711.      invocation coming from successive rows of a table or subquery.  The

  712.      preferred way to do this is to use the <code class="literal">LATERAL</code> key word,

  713.      which is described in <a class="xref" href="queries-table-expressions.html#QUERIES-LATERAL" title="7.2.1.5. LATERAL Subqueries">Section 7.2.1.5</a>.

  714.      Here is an example using a set-returning function to enumerate

  715.      elements of a tree structure:

  716. 

  717. </p><pre class="screen">

  718. SELECT * FROM nodes;

  719.    name    | parent

  720. -----------+--------

  721.  Top       |

  722.  Child1    | Top

  723.  Child2    | Top

  724.  Child3    | Top

  725.  SubChild1 | Child1

  726.  SubChild2 | Child1

  727. (6 rows)

  728. 

  729. CREATE FUNCTION listchildren(text) RETURNS SETOF text AS $$

  730.     SELECT name FROM nodes WHERE parent = $1

  731. $$ LANGUAGE SQL STABLE;

  732. 

  733. SELECT * FROM listchildren('Top');

  734.  listchildren

  735. --------------

  736.  Child1

  737.  Child2

  738.  Child3

  739. (3 rows)

  740. 

  741. SELECT name, child FROM nodes, LATERAL listchildren(name) AS child;

  742.   name  |   child

  743. --------+-----------

  744.  Top    | Child1

  745.  Top    | Child2

  746.  Top    | Child3

  747.  Child1 | SubChild1

  748.  Child1 | SubChild2

  749. (5 rows)

  750. </pre><p>

  751. 

  752.      This example does not do anything that we couldn't have done with a

  753.      simple join, but in more complex calculations the option to put

  754.      some of the work into a function can be quite convenient.

  755.     </p><p>

  756.      Functions returning sets can also be called in the select list

  757.      of a query.  For each row that the query

  758.      generates by itself, the set-returning function is invoked, and an output

  759.      row is generated for each element of the function's result set.

  760.      The previous example could also be done with queries like

  761.      these:

  762. 

  763. </p><pre class="screen">

  764. SELECT listchildren('Top');

  765.  listchildren

  766. --------------

  767.  Child1

  768.  Child2

  769.  Child3

  770. (3 rows)

  771. 

  772. SELECT name, listchildren(name) FROM nodes;

  773.   name  | listchildren

  774. --------+--------------

  775.  Top    | Child1

  776.  Top    | Child2

  777.  Top    | Child3

  778.  Child1 | SubChild1

  779.  Child1 | SubChild2

  780. (5 rows)

  781. </pre><p>

  782. 

  783.      In the last <code class="command">SELECT</code>,

  784.      notice that no output row appears for <code class="literal">Child2</code>, <code class="literal">Child3</code>, etc.

  785.      This happens because <code class="function">listchildren</code> returns an empty set

  786.      for those arguments, so no result rows are generated.  This is the same

  787.      behavior as we got from an inner join to the function result when using

  788.      the <code class="literal">LATERAL</code> syntax.

  789.     </p><p>

  790.      <span class="productname">PostgreSQL</span>'s behavior for a set-returning function in a

  791.      query's select list is almost exactly the same as if the set-returning

  792.      function had been written in a <code class="literal">LATERAL FROM</code>-clause item

  793.      instead.  For example,

  794. </p><pre class="programlisting">

  795. SELECT x, generate_series(1,5) AS g FROM tab;

  796. </pre><p>

  797.      is almost equivalent to

  798. </p><pre class="programlisting">

  799. SELECT x, g FROM tab, LATERAL generate_series(1,5) AS g;

  800. </pre><p>

  801.      It would be exactly the same, except that in this specific example,

  802.      the planner could choose to put <code class="structname">g</code> on the outside of the

  803.      nested-loop join, since <code class="structname">g</code> has no actual lateral dependency

  804.      on <code class="structname">tab</code>.  That would result in a different output row

  805.      order.  Set-returning functions in the select list are always evaluated

  806.      as though they are on the inside of a nested-loop join with the rest of

  807.      the <code class="literal">FROM</code> clause, so that the function(s) are run to

  808.      completion before the next row from the <code class="literal">FROM</code> clause is

  809.      considered.

  810.     </p><p>

  811.      If there is more than one set-returning function in the query's select

  812.      list, the behavior is similar to what you get from putting the functions

  813.      into a single <code class="literal">LATERAL ROWS FROM( ... )</code> <code class="literal">FROM</code>-clause

  814.      item.  For each row from the underlying query, there is an output row

  815.      using the first result from each function, then an output row using the

  816.      second result, and so on.  If some of the set-returning functions

  817.      produce fewer outputs than others, null values are substituted for the

  818.      missing data, so that the total number of rows emitted for one

  819.      underlying row is the same as for the set-returning function that

  820.      produced the most outputs.  Thus the set-returning functions

  821.      run <span class="quote">“<span class="quote">in lockstep</span>”</span> until they are all exhausted, and then

  822.      execution continues with the next underlying row.

  823.     </p><p>

  824.      Set-returning functions can be nested in a select list, although that is

  825.      not allowed in <code class="literal">FROM</code>-clause items.  In such cases, each level

  826.      of nesting is treated separately, as though it were

  827.      a separate <code class="literal">LATERAL ROWS FROM( ... )</code> item.  For example, in

  828. </p><pre class="programlisting">

  829. SELECT srf1(srf2(x), srf3(y)), srf4(srf5(z)) FROM tab;

  830. </pre><p>

  831.      the set-returning functions <code class="function">srf2</code>, <code class="function">srf3</code>,

  832.      and <code class="function">srf5</code> would be run in lockstep for each row

  833.      of <code class="structname">tab</code>, and then <code class="function">srf1</code> and <code class="function">srf4</code>

  834.      would be applied in lockstep to each row produced by the lower

  835.      functions.

  836.     </p><p>

  837.      Set-returning functions cannot be used within conditional-evaluation

  838.      constructs, such as <code class="literal">CASE</code> or <code class="literal">COALESCE</code>.  For

  839.      example, consider

  840. </p><pre class="programlisting">

  841. SELECT x, CASE WHEN x &gt; 0 THEN generate_series(1, 5) ELSE 0 END FROM tab;

  842. </pre><p>

  843.      It might seem that this should produce five repetitions of input rows

  844.      that have <code class="literal">x &gt; 0</code>, and a single repetition of those that do

  845.      not; but actually, because <code class="function">generate_series(1, 5)</code> would be

  846.      run in an implicit <code class="literal">LATERAL FROM</code> item before

  847.      the <code class="literal">CASE</code> expression is ever evaluated, it would produce five

  848.      repetitions of every input row.  To reduce confusion, such cases produce

  849.      a parse-time error instead.

  850.     </p><div class="note"><h3 class="title">Note</h3><p>

  851.       If a function's last command is <code class="command">INSERT</code>, <code class="command">UPDATE</code>,

  852.       or <code class="command">DELETE</code> with <code class="literal">RETURNING</code>, that command will

  853.       always be executed to completion, even if the function is not declared

  854.       with <code class="literal">SETOF</code> or the calling query does not fetch all the

  855.       result rows.  Any extra rows produced by the <code class="literal">RETURNING</code>

  856.       clause are silently dropped, but the commanded table modifications

  857.       still happen (and are all completed before returning from the function).

  858.      </p></div><div class="note"><h3 class="title">Note</h3><p>

  859.       Before <span class="productname">PostgreSQL</span> 10, putting more than one

  860.       set-returning function in the same select list did not behave very

  861.       sensibly unless they always produced equal numbers of rows.  Otherwise,

  862.       what you got was a number of output rows equal to the least common

  863.       multiple of the numbers of rows produced by the set-returning

  864.       functions.  Also, nested set-returning functions did not work as

  865.       described above; instead, a set-returning function could have at most

  866.       one set-returning argument, and each nest of set-returning functions

  867.       was run independently.  Also, conditional execution (set-returning

  868.       functions inside <code class="literal">CASE</code> etc) was previously allowed,

  869.       complicating things even more.

  870.       Use of the <code class="literal">LATERAL</code> syntax is recommended when writing

  871.       queries that need to work in older <span class="productname">PostgreSQL</span> versions,

  872.       because that will give consistent results across different versions.

  873.       If you have a query that is relying on conditional execution of a

  874.       set-returning function, you may be able to fix it by moving the

  875.       conditional test into a custom set-returning function.  For example,

  876. </p><pre class="programlisting">

  877. SELECT x, CASE WHEN y &gt; 0 THEN generate_series(1, z) ELSE 5 END FROM tab;

  878. </pre><p>

  879.       could become

  880. </p><pre class="programlisting">

  881. CREATE FUNCTION case_generate_series(cond bool, start int, fin int, els int)

  882.   RETURNS SETOF int AS $$

  883. BEGIN

  884.   IF cond THEN

  885.     RETURN QUERY SELECT generate_series(start, fin);

  886.   ELSE

  887.     RETURN QUERY SELECT els;

  888.   END IF;

  889. END$$ LANGUAGE plpgsql;

  890. 

  891. SELECT x, case_generate_series(y &gt; 0, 1, z, 5) FROM tab;

  892. </pre><p>

  893.       This formulation will work the same in all versions

  894.       of <span class="productname">PostgreSQL</span>.

  895.      </p></div></div><div class="sect2" id="XFUNC-SQL-FUNCTIONS-RETURNING-TABLE"><div class="titlepage"><div><div><h3 class="title">37.5.9. <acronym class="acronym">SQL</acronym> Functions Returning <code class="literal">TABLE</code></h3></div></div></div><a id="id-1.8.3.8.17.2" class="indexterm"></a><p>

  896.      There is another way to declare a function as returning a set,

  897.      which is to use the syntax

  898.      <code class="literal">RETURNS TABLE(<em class="replaceable"><code>columns</code></em>)</code>.

  899.      This is equivalent to using one or more <code class="literal">OUT</code> parameters plus

  900.      marking the function as returning <code class="literal">SETOF record</code> (or

  901.      <code class="literal">SETOF</code> a single output parameter's type, as appropriate).

  902.      This notation is specified in recent versions of the SQL standard, and

  903.      thus may be more portable than using <code class="literal">SETOF</code>.

  904.     </p><p>

  905.      For example, the preceding sum-and-product example could also be

  906.      done this way:

  907. 

  908. </p><pre class="programlisting">

  909. CREATE FUNCTION sum_n_product_with_tab (x int)

  910. RETURNS TABLE(sum int, product int) AS $$

  911.     SELECT $1 + tab.y, $1 * tab.y FROM tab;

  912. $$ LANGUAGE SQL;

  913. </pre><p>

  914. 

  915.      It is not allowed to use explicit <code class="literal">OUT</code> or <code class="literal">INOUT</code>

  916.      parameters with the <code class="literal">RETURNS TABLE</code> notation — you must

  917.      put all the output columns in the <code class="literal">TABLE</code> list.

  918.     </p></div><div class="sect2" id="id-1.8.3.8.18"><div class="titlepage"><div><div><h3 class="title">37.5.10. Polymorphic <acronym class="acronym">SQL</acronym> Functions</h3></div></div></div><p>

  919.      <acronym class="acronym">SQL</acronym> functions can be declared to accept and

  920.      return the polymorphic types <code class="type">anyelement</code>,

  921.      <code class="type">anyarray</code>, <code class="type">anynonarray</code>,

  922.      <code class="type">anyenum</code>, and <code class="type">anyrange</code>.  See <a class="xref" href="extend-type-system.html#EXTEND-TYPES-POLYMORPHIC" title="37.2.5. Polymorphic Types">Section 37.2.5</a> for a more detailed

  923.      explanation of polymorphic functions. Here is a polymorphic

  924.      function <code class="function">make_array</code> that builds up an array

  925.      from two arbitrary data type elements:

  926. </p><pre class="screen">

  927. CREATE FUNCTION make_array(anyelement, anyelement) RETURNS anyarray AS $$

  928.     SELECT ARRAY[$1, $2];

  929. $$ LANGUAGE SQL;

  930. 

  931. SELECT make_array(1, 2) AS intarray, make_array('a'::text, 'b') AS textarray;

  932.  intarray | textarray

  933. ----------+-----------

  934.  {1,2}    | {a,b}

  935. (1 row)

  936. </pre><p>

  937.     </p><p>

  938.      Notice the use of the typecast <code class="literal">'a'::text</code>

  939.      to specify that the argument is of type <code class="type">text</code>. This is

  940.      required if the argument is just a string literal, since otherwise

  941.      it would be treated as type

  942.      <code class="type">unknown</code>, and array of <code class="type">unknown</code> is not a valid

  943.      type.

  944.      Without the typecast, you will get errors like this:

  945. </p><pre class="screen">

  946. <code class="computeroutput">

  947. ERROR:  could not determine polymorphic type because input has type "unknown"

  948. </code>

  949. </pre><p>

  950.     </p><p>

  951.      It is permitted to have polymorphic arguments with a fixed

  952.      return type, but the converse is not. For example:

  953. </p><pre class="screen">

  954. CREATE FUNCTION is_greater(anyelement, anyelement) RETURNS boolean AS $$

  955.     SELECT $1 &gt; $2;

  956. $$ LANGUAGE SQL;

  957. 

  958. SELECT is_greater(1, 2);

  959.  is_greater

  960. ------------

  961.  f

  962. (1 row)

  963. 

  964. CREATE FUNCTION invalid_func() RETURNS anyelement AS $$

  965.     SELECT 1;

  966. $$ LANGUAGE SQL;

  967. ERROR:  cannot determine result data type

  968. DETAIL:  A function returning a polymorphic type must have at least one polymorphic argument.

  969. </pre><p>

  970.     </p><p>

  971.      Polymorphism can be used with functions that have output arguments.

  972.      For example:

  973. </p><pre class="screen">

  974. CREATE FUNCTION dup (f1 anyelement, OUT f2 anyelement, OUT f3 anyarray)

  975. AS 'select $1, array[$1,$1]' LANGUAGE SQL;

  976. 

  977. SELECT * FROM dup(22);

  978.  f2 |   f3

  979. ----+---------

  980.  22 | {22,22}

  981. (1 row)

  982. </pre><p>

  983.     </p><p>

  984.      Polymorphism can also be used with variadic functions.

  985.      For example:

  986. </p><pre class="screen">

  987. CREATE FUNCTION anyleast (VARIADIC anyarray) RETURNS anyelement AS $$

  988.     SELECT min($1[i]) FROM generate_subscripts($1, 1) g(i);

  989. $$ LANGUAGE SQL;

  990. 

  991. SELECT anyleast(10, -1, 5, 4);

  992.  anyleast 

  993. ----------

  994.        -1

  995. (1 row)

  996. 

  997. SELECT anyleast('abc'::text, 'def');

  998.  anyleast 

  999. ----------

  1000.  abc

  1001. (1 row)

  1002. 

  1003. CREATE FUNCTION concat_values(text, VARIADIC anyarray) RETURNS text AS $$

  1004.     SELECT array_to_string($2, $1);

  1005. $$ LANGUAGE SQL;

  1006. 

  1007. SELECT concat_values('|', 1, 4, 2);

  1008.  concat_values 

  1009. ---------------

  1010.  1|4|2

  1011. (1 row)

  1012. </pre><p>

  1013.     </p></div><div class="sect2" id="id-1.8.3.8.19"><div class="titlepage"><div><div><h3 class="title">37.5.11. <acronym class="acronym">SQL</acronym> Functions with Collations</h3></div></div></div><a id="id-1.8.3.8.19.2" class="indexterm"></a><p>

  1014.      When a SQL function has one or more parameters of collatable data types,

  1015.      a collation is identified for each function call depending on the

  1016.      collations assigned to the actual arguments, as described in <a class="xref" href="collation.html" title="23.2. Collation Support">Section 23.2</a>.  If a collation is successfully identified

  1017.      (i.e., there are no conflicts of implicit collations among the arguments)

  1018.      then all the collatable parameters are treated as having that collation

  1019.      implicitly.  This will affect the behavior of collation-sensitive

  1020.      operations within the function.  For example, using the

  1021.      <code class="function">anyleast</code> function described above, the result of

  1022. </p><pre class="programlisting">

  1023. SELECT anyleast('abc'::text, 'ABC');

  1024. </pre><p>

  1025.      will depend on the database's default collation.  In <code class="literal">C</code> locale

  1026.      the result will be <code class="literal">ABC</code>, but in many other locales it will

  1027.      be <code class="literal">abc</code>.  The collation to use can be forced by adding

  1028.      a <code class="literal">COLLATE</code> clause to any of the arguments, for example

  1029. </p><pre class="programlisting">

  1030. SELECT anyleast('abc'::text, 'ABC' COLLATE "C");

  1031. </pre><p>

  1032.      Alternatively, if you wish a function to operate with a particular

  1033.      collation regardless of what it is called with, insert

  1034.      <code class="literal">COLLATE</code> clauses as needed in the function definition.

  1035.      This version of <code class="function">anyleast</code> would always use <code class="literal">en_US</code>

  1036.      locale to compare strings:

  1037. </p><pre class="programlisting">

  1038. CREATE FUNCTION anyleast (VARIADIC anyarray) RETURNS anyelement AS $$

  1039.     SELECT min($1[i] COLLATE "en_US") FROM generate_subscripts($1, 1) g(i);

  1040. $$ LANGUAGE SQL;

  1041. </pre><p>

  1042.      But note that this will throw an error if applied to a non-collatable

  1043.      data type.

  1044.     </p><p>

  1045.      If no common collation can be identified among the actual arguments,

  1046.      then a SQL function treats its parameters as having their data types'

  1047.      default collation (which is usually the database's default collation,

  1048.      but could be different for parameters of domain types).

  1049.     </p><p>

  1050.      The behavior of collatable parameters can be thought of as a limited

  1051.      form of polymorphism, applicable only to textual data types.

  1052.     </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="xproc.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extend.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="xfunc-overload.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">37.4. User-Defined Procedures </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 37.6. Function Overloading</td></tr></table></div></body></html>
上海开阖软件有限公司 沪ICP备12045867号-1