Re: BIGINT Field Size

bill.reger=lADxs7XRq0eakBO8gow8eQ@public.gmane.org wrote:

Just out of curiosity, does anyone know why 8-byte Integer fields (type
BIGINT) are required to be defined as length 20 when the highest and lowest
allowed values are only 19 digits?  The allowed range of values is
documented to be from -9,223,372,036,854,775,808 to
9,223,372,036,854,775,807 (19 digits in each case).

All the other Integer data types require lengths that equal their range of
allowed values.  For example SMALLINT fields have a range from -32,768 to
32,767.  All valid integer field definitions are shown below:

D TinyInt         S              3I 0
D SmallInt        S              5I 0
D Integer         S             10I 0
D BigInt          S             20I 0

Like I said, I'm just curious.

Bill

A simple design decision.  Back when we added 2 and 4 byte integer
and unsigned variables, we had to decide between defining the
variable in terms of bytes (that is, 2I, 4I, 2U, & 4U) or in terms
of digits (5I0, 10I0, 5U0, & 10U0).  There were advantages and
disadvantages to both approaches, and in the end, we decided on
number of digits for consistency with the decimal numeric formats.

The next release, we added float, and number of digits really didn't
make sense there, thus 4F and 8F.  In retrospect, if we realized
that at the time we added integer and unsigned, that may have tipped
the scales towards 2I, 4I, etc.

That brings us to the 1 and 8 bytes integer and unsigned numerics.
An 8 byte unsigned can hold a 20 digit value, but unfortunately, an
8 byte integer only goes up to 19 digits.  To be consistent, we
defined both the 8 byte unsigned and the 8 byte integer as 20 digits.

You might then ask, what if we ever went to 16 byte integer and
unsigned?  Fortunately, integer and unsigned are consistent.  But
unfortunately, it's an odd number of digits - 39.  Would we define
those formats as 39I0 and 39U0?  Or would we use 40I0 and 40U0?  Who
knows?  Fortunately, we don't foresee a need to make that particular
design decision any time soon.

Oh BTW, talking of numerics, in V5R2 we increased the maximum size
of a packed decimal variable to a whopping 31 digits!

Cheers!  Hans