> This would seem to give license for the result of AVG() on an int4 field
> to be NUMERIC with a fraction part, but not FLOAT. But I suspect we
> could get away with making it be FLOAT anyway.
Sure, that can't be worse in practice than what we do now. But it is
interesting that we are currently SQL92 conforming (except for that
nasty overflow business; they probably don't mention that ;).
For int2/int4, we could bump the accumulator to int8 (certainly faster
than our numeric implementation?), but there are a very few platforms
which don't support int8 and we shouldn't break the aggregates for
them. We could get around that by defining explicit routines to be
used in the aggregates, and then having some #ifdef alternate code if
int8 is not available...
Tom, do you think that a hack in the aggregate support code which
compares the pointer returned to the pointer input, then pfree'ing the
input area if they differ, would fix the major leakage? We could even
have a backend global variable which enables/disables the feature to
allow performance tuning.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
