Re: Floating point numbers in ldap

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Lorenzo Pastrana writes:
> I can't find any mentions of floating point/real data types in ldap
> attributes syntax,

There is no standardized floating point LDAP syntax.

> I've been reading the laconic 'Numeric Sting' specifications :
> Would this work ok (matching & ordering) with a 1.997 value ?

No, Numeric String does not allow a decimal point.

> 6.23. Numeric String
> 
>    ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
> 
>    The encoding of a string in this syntax is the string value itself.
>    Example:

This is from the obsolete RFC 2251-2256 standards.  Read the current
LDAP standard instead, RFCs 4510-4519.  Syntaxes are in RFC 4517.
Many things including syntaxes are described more carefully than in
earlier RFCs.  E.g. explanations have been copied from the X.500
standard so they can mostly be read without cross-referencing X.500.

> If not, how do I get ldap to match and order floating point scalars ?

You have to implement them yourself - either in the client or
in a module you "moduleload" into the server in slapd.conf.

If you implement it in the client:
- Use a syntax like IA5 String or Octet String.
- These syntaxes' ORDERING rules sort as strings - so to get correct
  ordering you'll likely want to invent a format where
  memcmp(num1, num2) < 0 if num1 < num2.
- Store normalized values so they can be compared for equality.
  (E.g. if you use a text format, don't store trailing zeroes.)
You cannot index these syntaxes for inequality searches though.
I.e. a search for (val<=3.1) will not use an index, it will
examine each entry in scope.

If you implement in the server and want indexing for inequality to work,
the values stored in the index file must be sortable.  Look at
integerIndexer()+integerFilter() in servers/slapd/schema_init.c for an
example.  An implementation in the server will also allow you to
store non-normalized values and have the server normalize before
comparing.  (At the expense of some server-side CPU time, of course.)

-- 
Hallvard