DISTINCT ON()

Just as a side note, this is precisely what DISTINCT ON() does (not to be confused with DISTINCT)

SELECT DISTINCT ON ( expression [, ...] ) keeps only the first row of each set of rows where the given expressions evaluate to equal. The DISTINCT ON expressions are interpreted using the same rules as for ORDER BY (see above). Note that the "first row" of each set is unpredictable unless ORDER BY is used to ensure that the desired row appears first. For example

So if you were to write,

SELECT myFirstAgg(z)
FROM foo
GROUP BY x,y;

It's effectively

SELECT DISTINCT ON(x,y) z
FROM foo;
-- ORDER BY z;

In that it takes the first z. There are two important differences,

1. You can also select other columns at no cost of further aggregation..

   SELECT DISTINCT ON(x,y) z, k, r, t, v
   FROM foo;
   -- ORDER BY z, k, r, t, v;
   

2. Because there is no GROUP BY you can not use (real) aggregates with it.

   CREATE TABLE foo AS
   SELECT * FROM ( VALUES
     (1,2,3),
     (1,2,4),
     (1,2,5)
   ) AS t(x,y,z);
   
   SELECT DISTINCT ON (x,y) z, sum(z)
   FROM foo;
   
   -- fails, as you should expect.
   SELECT DISTINCT ON (x,y) z, sum(z)
   FROM foo;
   
   -- would not otherwise fail.
   SELECT myFirstAgg(z), sum(z)
   FROM foo
   GROUP BY x,y;
   

Don't forget ORDER BY

Also, while I didn't bold it then I will now

Note that the "first row" of each set is unpredictable unless ORDER BY is used to ensure that the desired row appears first. For example

Always use an ORDER BY with DISTINCT ON

Using an Ordered-Set Aggregate Function

I imagine a lot of people are looking for first_value, Ordered-Set Aggregate Functions. Just wanted to throw that out there. It would look like this, if the function existed:

SELECT a, b, first_value() WITHIN GROUP (ORDER BY z)    
FROM foo
GROUP BY a,b;

But, alas you can do this.

SELECT a, b, percentile_disc(0) WITHIN GROUP (ORDER BY z)   
FROM foo
GROUP BY a,b;

This is due to relation attributes (defined in pg_class and pg_attribute, or defined dynamically from a select statement) supporting modifiers (via pg_attribute.atttypmod), whilst function parameters do not. Modifiers are lost when processed through functions, and since all operators are handled via functions, modifiers are lost when processed by operators as well.

Functions with output values, or that return sets of record, or the equivalent returns table(...) are also unable to retain any modifiers included in the definition. However, tables that return setof <type> will retain (actually, probably typecast to) any modifiers defined for type in pg_attribute.