Re: Collation versioning

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 <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
wrote:

> >>>>> "Douglas" == Douglas Doole <dougdoole(at)gmail(dot)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)
>