Changes by Michael Bayer (@zzzeek):

• changed title from "implement "DISTINCT ON" for PG; remove old "distin" to "add array arg to select().distinct() query().disti"

Changes by Michael Bayer (@zzzeek):

• changed milestone from "0.5.0" to "0.5.xx"

Anonymous wrote:

SQL for DISTINCT ON seem to be in postgresql dialect adapter already for 0.5.5/0.6, so it seems just a matter of adding a few lines to Query.distinct.

Just found myself in need of this feature, so wrote a simple implementation for query class.[BR]
Prehaps someone might find this patch useful, at least while it's not implemented in trunk.

Anonymous wrote:

Wow, three years and “awaiting triage”...

To underline the severity here, I show how a decent group_by is affected:

SELECT a, b, c FROM x GROUP BY a

gets an error with PostgreSQL, because it doesn’t like to have b and c outside of aggregate functions. A DISTINCT ON a should be used in stead, which gives us any random b and c that fits -- that’s what I want.

Michael Bayer (@zzzeek) wrote:

Replying to guest:

Wow, three years and “awaiting triage”...

To underline the severity here, I show how a decent group_by is affected:

SELECT a, b, c FROM x GROUP BY a

gets an error with PostgreSQL, because it doesn’t like to have b and c outside of aggregate functions. A DISTINCT ON a should be used in stead, which gives us any random b and c that fits -- that’s what I want.

GROUP BY is mostly to do with grouping so that aggregates can be applied. The above query can link the selection of 'b' and 'c' to that of 'a' via a subquery, which is probably why I never find myself needing "DISTINCT ON".

Changes by Michael Bayer (@zzzeek):

• changed milestone from "0.6.xx" to "0.7.0"

Michael Bayer (@zzzeek) wrote:

note a more complete patch has been attached but still needs tests.

Michael Bayer (@zzzeek) wrote:

3f9a343

Changes by Michael Bayer (@zzzeek):

• changed status to closed