If you’ve recently upgraded to PostgreSQL 17 and suddenly started seeing errors about colliculocale not existing, you’re not alone. This column was quietly renamed to colllocale in commit f696c0cd, breaking queries that relied on the old name.

Now, any code that referenced pg_collation.colliculocale throws errors because the column is just gone. Developers are left with two choices: update their queries or stick with an older PostgreSQL version.

For example, a query like this:

SELECT cl.slug, cl.lang, COALESCE(pc.collname, 'C') AS collate_name
FROM (
    SELECT COALESCE(SPLIT_PART(languages, ',', 1), 'en') AS lang, slug
    FROM country_info
) AS cl
LEFT JOIN pg_collation pc ON cl.lang = pc.colliculocale::text;

Now throws errors because colliculocale no longer exists. Developers will need to update their queries… or stay on older versions of PostgreSQL.

The changes make sense for future-proofing PostgreSQL’s collation system, but it would have been nice if the migration path was smoother. Instead of outright renaming it, they could have introduced colllocale while keeping colliculocale as an alias for backward compatibility. Other databases have done this, and PostgreSQL itself has kept deprecated fields around before. A simple alias in C would have saved a lot of hassle.

Moving Forward⌗

Hopefully, PostgreSQL keeps backward compatibility in mind for future changes. Breaking queries in an upgrade—without an alias, deprecation period, or migration path—just makes life harder for developers. If you’re upgrading, double-check your queries. And if you’re maintaining legacy systems… well, good luck.