Postgres case-insensitive matching: A missing feature or a matter of defaults?
Postgres users should ultimately decide whether they can live with the limitations of pattern matching and choose, for instance, a LIKE operator that behaves the MySQL or MSSQL way, since that approach is acceptable in the vast majority of cases and is less cumbersome than alternatives like citext or lower() indexes.
A common workaround, especially in French systems, is to keep a dedicated search column alongside a "real" column, storing the name in plain ASCII, uppercase, for straightforward sorting and searching. This sidesteps querying users about accents at data entry time, which employees often don't want to do.
That pattern isn't always necessary, though. For applications that store only ASCII and reject Unicode outright—given downstream systems wouldn't accept it anyway—the extra investment in accent handling is unwarranted, even if that stance draws criticism from the rest of the world.
The bigger opportunity for SQL engines in 2022 is interoperability, even at the cost of stylistic purity. Supporting syntax like select top 1 * from table in Postgres would ease application migrations, since the parser cannot be extended by plugins. Also, the requirement to add collate to each column feels like a missing feature: specifying database- or schema-level defaults for collation would be far more convenient.
