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.)
On Sun, Sep 16, 2018 at 11:39 AM Andrew Gierth <and...@tao11.riddles.org.uk> wrote: > >>>>> "Douglas" == Douglas Doole <dougdo...@gmail.com> writes: > > 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.) > > -- > Andrew (irc:RhodiumToad) >
