From: | Tom Lane <tgl(at)hub(dot)org> |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql/ oc/src/sgml/func.sgml rc/backend/utils/ ... |
Date: | 2001-08-14 22:21:59 |
Message-ID: | 200108142221.f7EMLxk72798@hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
CVSROOT: /home/projects/pgsql/cvsroot
Module name: pgsql
Changes by: tgl(at)hub(dot)org 01/08/14 18:21:59
Modified files:
doc/src/sgml : func.sgml
src/backend/utils/adt: int8.c numeric.c oid.c
src/backend/utils/fmgr: fmgr.c
src/include/catalog: catversion.h pg_aggregate.h pg_proc.h
src/include/utils: builtins.h int8.h
src/test/regress/expected: opr_sanity.out rules.out
src/test/regress/sql: rules.sql
Log message:
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian - CVS | 2001-08-14 23:38:21 | pgsql/doc/src/sgml release.sgml |
Previous Message | Bruce Momjian - CVS | 2001-08-14 21:22:09 | pgsql/ /Tag: /REL7_1_STABLE /HISTORY /register ... |