diff options
author | Neil Conway <neilc@samurai.com> | 2007-01-16 21:41:14 +0000 |
---|---|---|
committer | Neil Conway <neilc@samurai.com> | 2007-01-16 21:41:14 +0000 |
commit | cf57ef4e506cd87195baa76213326b1981644452 (patch) | |
tree | d46388824c263a2c2737a2ac5283706f065f634c /src/backend/access/gist/gistget.c | |
parent | da07c81fe3672fdc216b923f7abcde5d23ad0a6a (diff) | |
download | postgresql-cf57ef4e506cd87195baa76213326b1981644452.tar.gz postgresql-cf57ef4e506cd87195baa76213326b1981644452.zip |
Implement width_bucket() for the float8 data type.
The implementation is somewhat ugly logic-wise, but I don't see an
easy way to make it more concise.
When writing this, I noticed that my previous implementation of
width_bucket() doesn't handle NaN correctly:
postgres=# select width_bucket('NaN', 1, 5, 5);
width_bucket
--------------
6
(1 row)
AFAICS SQL:2003 does not define a NaN value, so it doesn't address how
width_bucket() should behave here. The patch changes width_bucket() so
that ereport(ERROR) is raised if NaN is specified for the operand or the
lower or upper bounds to width_bucket(). For float8, NaN is disallowed
for any of the floating-point inputs, and +/- infinity is disallowed
for the histogram bounds (but allowed for the operand).
Update docs and regression tests, bump the catversion.
Diffstat (limited to 'src/backend/access/gist/gistget.c')
0 files changed, 0 insertions, 0 deletions