David Rowley <dgrowleyml@gmail.com> writes:
> My point was more that since sum(float) can give different results if it
> used an index scan rather than a seq scan, trying to get the inverse
> transition to match something that gives varying results sounds like a
> tricky task to take on.
This is just a variant of the same excuse we heard before. The question
is not whether sum(float8) can give bad results; the question is whether
we are going to break applications that are using it carefully (ie with
an appropriate ORDER BY) and expecting to get good results.
>> Secondly, you'd really need a second aggregate definition - usually, the
>> non-invertible aggregate will get away with a much smaller state
>> representation.
Yeah. I think the idea of multiple transition functions in a single
aggregate definition is pretty broken to start with, but the likelihood
that they couldn't share aggregate state types puts it completely beyond
sanity. We're not going to start inventing "stype2" etc.
regards, tom lane