Direct arguments are typically used for things like
    percentile fractions, which only make sense as a single value per
    aggregation calculation.  The direct argument list can be empty; in this
    case, write just <literal>()</literal> not <literal>(*)</literal>.
    (<productname>PostgreSQL</productname> will actually accept either spelling, but
    only the first way conforms to the SQL standard.)
   </para>

   <para>
    <indexterm>
     <primary>median</primary>
     <seealso>percentile</seealso>
    </indexterm>
    An example of an ordered-set aggregate call is:

<programlisting>
SELECT percentile_cont(0.5) WITHIN GROUP (ORDER BY income) FROM households;
 percentile_cont
-----------------
           50489
</programlisting>

   which obtains the 50th percentile, or median, value of
   the <structfield>income</structfield> column from table <structname>households</structname>.
   Here, <literal>0.5</literal> is a direct argument; it would make no sense
   for the percentile fraction to be a value varying across rows.
   </para>

   <para>
    If <literal>FILTER</literal> is specified, then only the input
    rows for which the <replaceable>filter_clause</replaceable>
    evaluates to true are fed to the aggregate function; other rows
    are discarded.  For example:
<programlisting>
SELECT
    count(*) AS unfiltered,
    count(*) FILTER (WHERE i &lt; 5) AS filtered
FROM generate_series(1,10) AS s(i);
 unfiltered | filtered
------------+----------
         10 |        4
(1 row)
</programlisting>
   </para>

   <para>
    The predefined aggregate functions are described in <xref
    linkend="functions-aggregate"/>.  Other aggregate functions can be added
    by the user.
   </para>

   <para>
    An aggregate expression can only appear in the result list or
    <literal>HAVING</literal> clause of a <command>SELECT</command> command.
    It is forbidden in other clauses, such as <literal>WHERE</literal>,
    because those clauses are logically evaluated before the results
    of aggregates are formed.
   </para>

   <para>
    When an aggregate expression appears in a subquery (see
    <xref linkend="sql-syntax-scalar-subqueries"/> and
    <xref linkend="functions-subquery"/>), the aggregate is normally
    evaluated over the rows of the subquery.  But an exception occurs
    if the aggregate's arguments (and <replaceable>filter_clause</replaceable>
    if any) contain only outer-level variables:
    the aggregate then belongs to the nearest such outer level, and is
    evaluated over the rows of that query.  The aggregate expression
    as a whole is then an outer reference for the subquery it appears in,
    and acts as a constant over any one evaluation of that subquery.
    The restriction about
    appearing only in the result list or <literal>HAVING</literal> clause
    applies with respect to the query level that the aggregate belongs to.
   </para>
  </sect2>

  <sect2 id="syntax-window-functions">
   <title>Window Function Calls</title>

   <indexterm zone="syntax-window-functions">
    <primary>window function</primary>
    <secondary>invocation</secondary>
   </indexterm>

   <indexterm zone="syntax-window-functions">
    <primary>OVER clause</primary>
   </indexterm>

   <para>
    A <firstterm>window function call</firstterm> represents the application
    of an aggregate-like function over some portion of the rows selected
    by a query.  Unlike non-window aggregate calls, this is not tied
    to grouping of the selected rows into a single output row &mdash; each
    row remains separate in the query output.  However the window function
    has access to all the rows that would be part of the current row's
    group according to the grouping specification (<literal>PARTITION BY</literal>
    list) of the window function call.
    The syntax of a window function call is one of the following:

<synopsis>
<replaceable>function_name</replaceable> (<optional><replaceable>expression</replaceable> <optional>, <replaceable>expression</replaceable>