As far as I can remember, the motivation behind list_to_existing_atom was not the fact that list_to_atom pollutes the atoms table during normal operation. However, it won't prevent atom table pollution when something goes wrong or somebody goes malicious (i.e., DoS attack).
I've just looked it up for you, the exact description is here: https://issues.apache.org/jira/browse/COUCHDB-829 - Klaus On Sun, 2011-01-02 at 08:06 -0500, Bob Dionne (JIRA) wrote: > list_to_existing_atom is too restrictive as used by couch_rep > ------------------------------------------------------------- > > Key: COUCHDB-1004 > URL: https://issues.apache.org/jira/browse/COUCHDB-1004 > Project: CouchDB > Issue Type: Bug > Components: Replication > Environment: erlang > Reporter: Bob Dionne > Priority: Minor > > > We'd like to additional information to db_info in BigCouch, such as the Q and > N constants for a given database. This causes replication to fail when > replicating from BigCouch to CouchDB due to the use of list_to_existing_atom > in couch_rep:dbinfo(... > > The claim is that list_to_atom pollutes the atoms table, however superficial > testing indicates this is not the case, list_to_atom when called repeatedly > seems to work fine. If this is true then consider reverting > list_to_existing_atom back to list_to_atom. >
