Andrew Gierth and...@tao11.riddles.org.uk writes:
A followup question: currently the code uses the datum interface for
tuplesort. Obviously with multiple columns the slot interface is used
instead; but is there any performance advantage for staying with the
datum interface for the
Quoth the comments in nodeAgg.c:
* We don't currently implement DISTINCT aggs for aggs having more
* than one argument. This isn't required for anything in the SQL
* spec, but really it ought to be implemented for
* feature-completeness. FIXME someday.
and:
* DISTINCT always suppresses
Andrew Gierth and...@tao11.riddles.org.uk writes:
Now the question: If the limit of one argument for DISTINCT aggs were
removed (which I'm considering doing as part of an update to the
aggregate ORDER BY patch I posted a while back), what should be the
behaviour of agg(distinct x,y) where one
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Andrew Gierth and...@tao11.riddles.org.uk writes:
Now the question: If the limit of one argument for DISTINCT aggs were
removed (which I'm considering doing as part of an update to the
aggregate ORDER BY patch I posted a while back), what should
Andrew Gierth and...@tao11.riddles.org.uk writes:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom I think you could probably just change it: make DISTINCT work as
Tom per regular DISTINCT (treat null like a value, keep one copy).
Tom All the spec-conforming aggregates are strict and would
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom I think you could probably just change it: make DISTINCT work as
Tom per regular DISTINCT (treat null like a value, keep one copy).
Tom All the spec-conforming aggregates are strict and would ignore
Tom the null in the next step anyway.
