h.goebel@goebel-consult.de wrote:

Full_Name: Version: 2.3.38 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.207.201.247)

Debugging marks in sql-statement may lead to wrong results.

The interface I implemented yields statements like this when using Thunderbird for searching for 'Klaus'. Thunderbird tries to look up in email, name and given name. Ans in my setup, search is restricted to "(objectclass=evolutionPerson)".

SELECT DISTINCT ldap_entries.id,res_partner_address.id, text('evolutionPerson') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,res_partner_address,ldap_entry_objclasses WHERE res_partner_address.id=ldap_entries.keyval AND ldap_entries.oc_map_id=1 AND 9=9 AND ((2=2 OR ( ldap_entries.id=ldap_entry_objclasses.entry_id AND ldap_entry_objclasses.oc_name='evolutionPerson')) AND (( upper(email) LIKE '%KLAUS%') OR (upper(name) LIKE '%KLAUS%') OR 7=7 OR (upper(substring(name from '\S+..$')) LIKE '%KLAUS%')))

1. "OR 7=7 OR" renders the whole last AND-clause useless: No selection is done on email, name or givenname. Thus all records are returned.

2. "2=2 OR" renders the restriction to a specific objectclass useless.

   In Bug 5198 Pierangelo Masarati say, that a good RDBMs is optimizing this part away. And exactly this is the problem.

This is required to implement attribute and objectClass inheritance, which is required by LDAP. So please don't call them "bugs", they're required hacks. If they're not in place, back-sql would give the wrong response to queries; if they're in place, back-sql would give the right response, possibly inefficiently on braindead RDBMSes. Please choose what you prefer: the wrong answer quickly or the right one maybe slower?

p.

Ing. Pierangelo Masarati OpenLDAP Core Team

SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------