Re: Collation versioning
От | Douglas Doole |
---|---|
Тема | Re: Collation versioning |
Дата | |
Msg-id | CADE5jYKgrRnTy69Z1JjR+mNCox+gMFp9YJWNci+9GMQcOjP0xQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Collation versioning (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Список | pgsql-hackers |
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@tao11.riddles.org.uk> wrote:
>>>>> "Douglas" == Douglas Doole <dougdoole@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)
В списке pgsql-hackers по дате отправления: