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.

1 files changed, 19 insertions, 1 deletions

diff --git a/src/backend/utils/adt/oid.c b/src/backend/utils/adt/oid.c
index 91dbf6c54eb..5eb65979f18 100644
--- a/src/backend/utils/adt/oid.c
+++ b/src/backend/utils/adt/oid.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $Header: /cvsroot/pgsql/src/backend/utils/adt/oid.c,v 1.45 2001/03/22 03:59:52 momjian Exp $
+ *	  $Header: /cvsroot/pgsql/src/backend/utils/adt/oid.c,v 1.46 2001/08/14 22:21:58 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -232,6 +232,24 @@ oidgt(PG_FUNCTION_ARGS)
 }
 
 Datum
+oidlarger(PG_FUNCTION_ARGS)
+{
+	Oid			arg1 = PG_GETARG_OID(0);
+	Oid			arg2 = PG_GETARG_OID(1);
+
+	PG_RETURN_OID((arg1 > arg2) ? arg1 : arg2);
+}
+
+Datum
+oidsmaller(PG_FUNCTION_ARGS)
+{
+	Oid			arg1 = PG_GETARG_OID(0);
+	Oid			arg2 = PG_GETARG_OID(1);
+
+	PG_RETURN_OID((arg1 < arg2) ? arg1 : arg2);
+}
+
+Datum
 oidvectoreq(PG_FUNCTION_ARGS)
 {
 	Oid		   *arg1 = (Oid *) PG_GETARG_POINTER(0);