"David E. Wheeler" <david@kineticode.com> writes:
> On Sep 1, 2010, at 10:12 AM, Tom Lane wrote:
>> Even more to the point, should we deliberately make this vaguer so that
>> we aren't finding ourselves with obsolete text again and again? You can
>> bet that people adding new aggregates in the future aren't going to
>> think to update this sentence, any more than happened with array_agg.
> Perhaps �consult the docs for each aggregate to determine how it handles NULLs.�
Hm, actually the whole para needs work. It was designed at a time when
DISTINCT automatically discarded nulls, which isn't true anymore, and
that fact was patched-in in a very awkward way too. Perhaps something
like
The first form of aggregate expression invokes the aggregate once for each input row. The second form is the
sameas the first, since <literal>ALL</literal> is the default. The third form invokes the aggregate once for each
distinctvalue, or set of values, of the expression(s) found in the input rows. The last form invokes the aggregate
oncefor each input row; since no particular input value is specified, it is generally only useful for the
<function>count(*)</function>aggregate function.
Most aggregate functions ignore null inputs, so that rows in which one or more of the expression(s) yield null are
discarded. (This can be assumed to be true, unless otherwise specified, for all built-in aggregates.)
Then we have to make sure array_agg is properly documented, but we
don't have to insert something into the description of every single
aggregate, which is what your proposal would require.
regards, tom lane