As always, the problem is always the underlying issue, even though the surface one is pretty ridiculous. If the council doesn't understand how to sanitise database input, imagine just how bad they are at the stuff that's mildly difficult or worse. Do NOT give any sensitive data to them, whatever you do!

It's not just queries though - but CSV exports, etc. - every single system that ever handles this data needs to handle them.

Searching if users omit the apostrophes, etc.

I'm sure that IT working in the council understand input sanitisation and escape sequences, but they're working to a broken standard.

The standard isn't the point. You can have a "search key" or "standards compliant name" column in a table, and also have a "sign name" column. Whoever came up with this plan was either a fool or likes annoying people (possibly those two things are the same thing).

And/or this is #145 on their to-do list, so after a good 15 months of postponing it, an overworked IT council guy told his supervisor "if you want X implemented without overhauling system Y just get rid of apostrophes" so this article happened.

Aside from making some signs grammatically incorrect, it means places/streets cannot be named after anyone with an apostrophe in their name without mangling their name. It's a bit ironic to honour people by failing to respect their name.

*dont

next to go will be capital letters

thenspaces

y not i fink sum ppl do that already in sum context nyway