Why is all of this implemented in SQL? Wouldn't it be better to do it in code with dedicated methods to filter stuff out? IMO logic inside of SQL queries just adds unnecessary complexity, implementing this in code would've been maintainable and testable.
Boss: "Hey Bob! People started spamming one of our boards, we are currently busy doing other things and cannot deploy new client, can you make filter with these 3 words and deploy it ASAP?"
Bob: "Sure no problem if it's only temporary"
--few months later
Chief architect:
"People are spamming more and more, we should design new system for these 234 new bad words, I need team of 7, two backend guys, 5 frontend guys and 4 weeks. It will also require minor rewrite of few external components."
Boss: "geez we're in the middle of sprint right now, Bob can you add these 234 words to existing filter? Make sure it's in production before lunch, thanks" (checks watches) "I have to go now, meeting with customer, bye".
It is FUNCTIONS so it is code like any other. Even SQL is code (declarative).
The reason is: This can be updated very easily and out-of-band of other deploys of the main application code.
To make this work it has to be super agile to update. Probably this version we are looking at is an old version that happened to be put in git. The functions in prod probably have several additions since.
