I don't want to hold you back from implementing the EQUALITY matching rule
for PostalAdress syntax.
But you could also just delete the whole attribute and re-add the value(s)
needed. (That's how the delta-modification works in web2ldap if the EQUALITY
matching rule is not implemented.)
Yes that's what i did to fix my test data, but specifically this
change was made indirectly by the collect.c overlay, not manually by
me, which populates attributes from a parent or template object
through to all the children of that object. I want to use the collect
overlay to make child objects have the same postalAddress (amoung
other attributes) of some parent or template object, such as some
superior ou entry that is component of the user's dn.
This issue arises as to what happens to when you try to edit
postalAddress in a child object which has collected an attribute from
some parent, what is presently happening is that the parent gets
another duplicate attribute value on the inherited attribute. In other
words it allows the change, but it cannot tell that the new attribute
value is the same as the old attribute value.
While this probably can be simply fixed by disallowing writes on
attributes of child object which are collect-ed from a parent, my
thought was that if there was an equality matching rule and it were
implemented, the update would fail or silently ignore the update (as
ldap would normally) because the attribute already has that value, and
it would be a tidier / more correct solution.