Re: Third thoughts about the DISTINCT MAX() problem

I wrote:
> Plan B was to try to revert to the way sort clause matching was
> done pre-8.3, that is have make_sort_from_pathkeys check first
> for a matching ressortgroupref tag before it goes looking for equal()
> expressions.

So I tried that, and after a whole bunch of regression test failures
I realize it won't work.  ressortgroupref tags are only guaranteed
unique within a given targetlist --- the values applicable in the
final result tlist might mean something else within a plan node further
down in the tree.  Since EquivalenceClasses are global to the whole
plan, trying to match them to tlist entries by ressortgroupref isn't
safe.

This actually calls into question the existing fix for making sure
we pick the right tlist entry when dealing with volatile ORDER BY
expressions.  I think it's all right because sorting by such expressions
could only occur at top tree level --- we'd never consider such an
expression as a mergejoin key, for instance.  But it seems fragile
and something we'll need to keep an eye on.

Anyway, it seems that the only remaining acceptable fix is the one
involving modifying the EquivalenceClasses when planagg.c makes
its substitutions.  Unless someone has another idea.
        regards, tom lane