Re: Add proper planner support for ORDER BY / DISTINCT aggregates

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> I think the behaviour of an ORDER BY in the query can also be pretty
> surprising.

Indeed. The fundamental question is this: in

> SELECT ARRAY[random(), random(), random()]
> FROM generate_series(1, 3)
> ORDER BY random();

are those four occurrences of random() supposed to refer to the
same value, or not? This only matters for volatile functions
of course; with stable or immutable functions, textually-equal
subexpressions should have the same value in any given row.

It is very clear what we are supposed to do for

SELECT random() FROM ... ORDER BY 1;

which sadly isn't legal SQL anymore. It gets fuzzy as soon
as we have

SELECT random() FROM ... ORDER BY random();

You could make an argument either way for those being the
same value or not, but historically we've concluded that
it's more useful to deem them the same value. Then the
behavior you show is not such a surprising extension,
although it could be argued that such matches should only
extend to identical top-level targetlist entries.

> The trouble is, if we tried to fix that, we'd risk changing some other
> behaviour that users may have come to rely on.

Yeah. I'm hesitant to try to adjust semantics here;
we're much more likely to get complaints than kudos.

regards, tom lane