Skip to content
  • Pierangelo Masarati's avatar
    05348c5f
    CHANGES: · 05348c5f
    Pierangelo Masarati authored
    - now all write operations appear to work correctly with PostgeSQL 7.0
    - all write operations have been made transactional (atomic writes to
      entries are committed separately only in case of complete^1 success
      while all other operations are rolled-back by default)
    - more cleanup and handling of exceptional conditions
    
    TODO:
    - deen to check with different databases and more up to date versions
      of both unixODBC and PostgreSQL.
    
    ^1: attribute add/modify/delete operations silently succeed if the
        appropriate add/delete proc does not exist for each attribute;
        this may be correct to hide undesired/unimplemented correspondence
        between LDAP and SQL databases; however, a more appropriate
        LDAP behavior would be a failure with LDAP_UNAVAILABLE if a
        single write operation cannot be executed for such reason
    05348c5f
    CHANGES:
    Pierangelo Masarati authored
    - now all write operations appear to work correctly with PostgeSQL 7.0
    - all write operations have been made transactional (atomic writes to
      entries are committed separately only in case of complete^1 success
      while all other operations are rolled-back by default)
    - more cleanup and handling of exceptional conditions
    
    TODO:
    - deen to check with different databases and more up to date versions
      of both unixODBC and PostgreSQL.
    
    ^1: attribute add/modify/delete operations silently succeed if the
        appropriate add/delete proc does not exist for each attribute;
        this may be correct to hide undesired/unimplemented correspondence
        between LDAP and SQL databases; however, a more appropriate
        LDAP behavior would be a failure with LDAP_UNAVAILABLE if a
        single write operation cannot be executed for such reason
Loading