Or zip codes as they’re called in the United States.
The Nominatim geocoder has trouble parsing address queries when its OSM database table contains invalid postcodes. For example when a building in OSM has addr:postcode=TX set then Nominatim will make an entry “TX is a postalcode in the United States”. When a user searches for an address containing “place1, TX, USA” Nominatim will search for “place1, USA near postcode TX” which might return a place by the same name, but outside Texas.
The technical solution is to disregard any data which doesn’t confirm to the country’s postcode standard, here 5 digits with optional 4 digits (“12345” or “12345-6789”). Not import into the database, skip in an intermediary step (calculating postcode center point or boundaries) or skip during query time. Nominatim issue 2017
In the meantime why not correct OSM data, could be fun.
First I went for obvious garbage: ‘$x1’, ‘null’, ‘0’, non-printable characters and such. Not a lot.
Then any postcodes not starting with a number. That turned out hundreds of city names (with or without postcode), street names or states codes. Splitting those values in iD editor was easy. For those formatted “TX 12345” I used the level0 editor state-by-state, it’s faster but still very manual.
Lastly it will be postcodes which are 3-4 or 6 digits. That will take the longest and often require local knowledge. Those “123XX” I think have little value, no search engine can make effective use of partial postcodes. At least in the US postcodes are not hierarchical enough.