Re: ordered indexing for integers

Howard Chu writes: > I guess you're really describing something like floating-point > representation, except our exponents are always positive. A mixture and floating point and DER, I suppose. I've hardly looked inside a floting-point number for decades. Fixed length like you say and "exponent" = "length it would have if represented exactly", as with floating-point. But with a lenght-of-length component and counted in octets, not bits, as in DER. And I don't see much point in doing the base-10 multiplication or division needed for true floating point. Unless floating-point hardware is sufficiently magical nowadays that it's an advantage to make use of it. I don't have a clue myself. I don't know if anyone uses huge enough integers in LDAP that it's a gain to avoid base10 conversion, but I don't know they don't either. Probably a bad idea now that I think of it, in case one later moves to an an LDAP/X.500-server with ASN.1 encoding, which will then have to convert between binary and decimal anyway.

Another point with huge integers is that one might store a group of them with small differences, and want an equality index to tell them apart. For that an index of <length, first digits, last digits> could be useful. Then the inequality index and inequality filter for a huge value would need to generate different index keys though. (The filter would need to replace the "last digits" part of huge values with 0x00... or 0xff...) I don't know if OpenLDAP's indexing supports that.

In any case, for similar reasons it might be an idea to keep supporting the old hash(decimal value) index format.