Andrew Gierth 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 single-column case?
No idea ... m
> "Tom" == Tom Lane 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.
>> Change it f
Andrew Gierth writes:
> "Tom" == Tom Lane 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 ste
> "Tom" == Tom Lane writes:
> Andrew Gierth 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(dis
Andrew Gierth 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 or both of x or y is nul
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 nu
