mirror of
https://github.com/postgres/postgres.git
synced 2025-11-07 19:06:32 +03:00
sum() on int2 and int4 columns now uses an int8, not numeric, accumulator
for speed reasons; its result type also changes to int8. avg() on these datatypes now accumulates the running sum in int8 for speed; but we still deliver the final result as numeric, so that fractional accuracy is preserved. count() now counts and returns in int8, not int4. I am a little nervous about this possibly breaking users' code, but there didn't seem to be a strong sentiment for avoiding the problem. If we get complaints during beta, we can change count back to int4 and add a "count8" aggregate. For that matter, users can do it for themselves with a simple CREATE AGGREGATE command; the int4inc function is still present, so no C hacking is needed. Also added max() and min() aggregates for OID that do proper unsigned comparison, instead of piggybacking on int4 aggregates. initdb forced.
This commit is contained in:
@@ -7,7 +7,7 @@
|
||||
* Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group
|
||||
* Portions Copyright (c) 1994, Regents of the University of California
|
||||
*
|
||||
* $Id: int8.h,v 1.26 2001/06/07 00:09:32 momjian Exp $
|
||||
* $Id: int8.h,v 1.27 2001/08/14 22:21:59 tgl Exp $
|
||||
*
|
||||
* NOTES
|
||||
* These data types are supported on all 64-bit architectures, and may
|
||||
@@ -74,6 +74,7 @@ extern Datum int8div(PG_FUNCTION_ARGS);
|
||||
extern Datum int8abs(PG_FUNCTION_ARGS);
|
||||
extern Datum int8fac(PG_FUNCTION_ARGS);
|
||||
extern Datum int8mod(PG_FUNCTION_ARGS);
|
||||
extern Datum int8inc(PG_FUNCTION_ARGS);
|
||||
extern Datum int8larger(PG_FUNCTION_ARGS);
|
||||
extern Datum int8smaller(PG_FUNCTION_ARGS);
|
||||
|
||||
|
||||
Reference in New Issue
Block a user