Re: Gauge32 as an index (guidelines Section 4.6.1.1)

["C. M. Heard" <heard@pobox.com>]

On Wed, 5 Feb 2003, Wijnen, Bert (Bert) wrote:
> > Keith's elaboration is now included in the part of Section 4.6.1.1
> > dealing with the selection of data types for index objects, in
> > accordance with discussions on the mailing list.
> > 
> One worry I now have is this: would any people be encouraged to start
> use Gauge32 as an INDEX ???

People SHOULD be encouraged to so do when it is the right thing to do.

Here is the exact text of the guidelines:

   - For integer-valued objects that appear in an INDEX clause or for
     integer-valued TCs that are to be used in an index column:

     - Unsigned32 with a range that excludes zero is RECOMMENDED for
       most index objects.  It is acceptable to include zero in the
       range when it is semantically significant or when it is used as
       the index value for a unique row with special properties.   Such
       usage SHOULD be clearly documented in the DESCRIPTION clause.

     - Integer32 or INTEGER with a non-negative range is acceptable.
       Again, zero SHOULD be excluded from the range except when it is
       semantically significant or when it is used as the index value
       for a unique row with special properties, and in such cases the
       usage SHOULD be clearly documented in the DESCRIPTION clause.

     - Use of Gauge32 is appropriate for index objects that have gauge
       semantics.

The contentious part is this last bullet.  Appearing in context, I
think it's just fine.  What this tells me is that folks who use
Gauge32 for an index when all they have is an arbitrary unsigned
number ought to be asked to change it to Unsigned32.  However, if
they have something with gauge semantics (like the temperature
variable in Randy's example) that they wish to use as a table index
to get a particular sort order, then using Gauge32 for that index
column is indeed the right thing to do.

I definitely agree that we want to discourage treating Gauge32 and
Unsigned32 as synonymous.  You may recall that the original version
of the guidelines (from last November) did that, and you and Juergen
Schoenwaelder objected to that (rightly so, I might add).  I then
swung to the opposite extreme, and put in words to actively
discourage using Gauge32 as an index (by saying it was NOT
RECOMMENDED).  Randy Presuhn and Andy Bierman both beat me up for
making a CLR (and they were right, too).  I think what's there now
strikes the correct balance:  people are encouraged to use
Unsigned32 for most cases, they are allowed (but not exactly
encouraged) to use Integer32 or INTEGER (with a positive range), and
Gauge32 is reserved for special cases where it fits.

//cmh