Les collations sont un souci majeur pour toute mise à jour du système d'exploitation et pour toute mise en place d'une réplication physique. En effet, pour ne pas avoir de corruption des index, il faut que le tri des données soit garanti identique entre les différents nœuds d'un cluster de réplication. Cela sous-entend la même version du fournisseur de collation, que ce soit la librairie C ou la librairie ICU. Dans le cas de la librairie C, cela sous-entend aussi la même version de la distribution Linux. Donc pas de mélange de système d'exploitation, pas de mise à jour du système d'exploitation, etc. C'est une limitation très gênante, avec des conséquences potentiellement graves. La version 17 améliore la donne en proposant un fournisseur interne de collation pour les encodage C (ASCII) et UTF-8. Comme le fournisseur est interne, les soucis de mises à jour systèmes disparaissent complètement. Cerise sur le gateau, les performances sont aussi au rendez-vous. Le fournisseur interne est bien plus performant que les autres fournisseurs. Il y a néanmoins des inconvénients à utiliser ce fournisseur. Les tris linguistiques ne sont pas gérés. De même, il n'est pas possible d'utiliser les comparaisons avancées. La création d'une base avec ce fournisseur doit passer par la clause `builtin_locale`, ainsi : ``` CREATE DATABASE nouvelle_base LOCALE_PROVIDER builtin BUILTIN_LOCALE "C.UTF-8" TEMPLATE template0; ``` L'article de Daniel Vérité (en anglais) apporte de nombreuses informations et de nombreux tests sur ce nouveau fournisseur. Vous le trouverez sur . Il existe aussi l'excellente conférence de Jeremy Schneider and Jeff Davis (ce dernier étant l'auteur de cette fonctionnalité sur ce sujet), conférence réalisée pendant l'événement « PGConf.dev 2024 ». [Elle est disponible sur YouTube](https://www.youtube.com/watch?v=KTA6oau7tl8).