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 is probably a bug that needs fixing, i'm considering the best option for a workaround.
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.
To paraphrase, i'd prefer to leave the decision as to whether the attribute MAY be written, to the access control system, and just work on the fact wether the attribute should be written (ie. it already has that value, so request should be silently ignored or errored, i favour the former) which is more correct IMHO, just disabling writes is ignoring the problem (although that also might be a nice feature).
Cheers Brett