search

asaskevich / govalidator

[Go] Package of validators and sanitizers for strings, numerics, slices and structs
MIT License
5.97k stars 554 forks source link

Suggestion of the implementation of postal codes validation #455

Open gabriellopes00 opened 2 years ago

gabriellopes00 commented 2 years ago

Feature Request

Q A
New Feature yes
RFC no
BC Break no

Summary

I've been thinking in a way of implementing postal code validation. The biggest problem, is that there are a lot of different patterns of postal codes around the world, so isn't possible to create a single regular expression and a unique function to validate it. I found in stack overflow a question asking for an ultimate postal code pattern, and i found this useful answer. As wee can see, there are around 158 postal code patterns in total, each one referring to a specific region/country in the world. So here is my suggestion: We could create a map (map[string]string), which the key is the country id (US, CN, FR, BR...), and the value is the regexp for it's postal code (the list might be long). Then, the function to validate the postal code would receive the country id in the first parameter, and the postal code in the second, this way we can find the country id in the map, and see if the received postal code matches with it's respective postal code pattern. What do u think?

sergeyglazyrindev commented 2 years ago

@asaskevich , I sent you a contact request on linkedin. I really don't understand, seems like you are not in prison in Belarus. And you stopped supporting thisd package -> it's ok, it's not your job. But we need to keep moving. Maybe you are tired from this package. It's ok too. Please reply, don't delete this comment.

gabriellopes00 commented 2 years ago

@asaskevich , I sent you a contact request on linkedin. I really don't understand, seems like you are not in prison in Belarus. And you stopped supporting thisd package -> it's ok, it's not your job. But we need to keep moving. Maybe you are tired from this package. It's ok too. Please reply, don't delete this comment.

I agree, it's ok not to have time to support the package, we understand, but it's been 8 months since we've had updates. There are too many people who use the package and it needs to be maintained.