Oh good. I'd missed that detail. So that eases the RI constraint concern. (In my previous job, we wanted case/accent insensitive collations, so equal did not mean binary equal which added a whole extra level of fun.)
Douglas> And constraints problems are even easier than triggers. Douglas> Consider a database with complex BI rules that are implemented Douglas> through triggers that fire when values are/are not equal. If Douglas> the equality of strings change, there could be bad data Douglas> throughout the tables.
Perhaps fortunately, collation changes cannot (in PG) affect the equality or non-equality of strings (at least of text/varchar/char types, citext is a different matter). For the builtin string types, PG follows the rule that if the collation calls the values equal, they are ordered secondarily in codepoint order; only byte-identical values can actually be equal (we need this in order for hashing to work in the absence of a strxfrm implementation that we can trust).
(This is the same rule used for string comparisons in Perl.)