Dennis Bjorklund <db@zigo.dhs.org> writes:
> On Wed, 7 Apr 2004, Tom Lane wrote:
>> If we copy a text index into a new database and claim that it is sorted
>> by some new locale, we'd be breaking things.
> How is this handled for encodings? You can very well have something in
> template1 in an encoding that is not compatible with the encoding you use
> to create a new database.
This is likely broken; but that's no excuse for creating similar
breakage for locale settings. Note that Peter's planned project would
hopefully clean up both of these issues.
In practice, we know that we have seen index failures from altering the
locale settings (back before we installed the code that locks down
LC_COLLATE/LC_CTYPE at initdb time). I do not recall having heard any
reports of index failures that could be traced to changing encoding.
This may be because strcoll() derives its assumptions about encoding
from the LC_CTYPE setting and doesn't actually know what PG thinks the
encoding is. So you might have a stored string that is illegal per the
current encoding, but nonetheless it will sort the same as it did in the
mother database.
regards, tom lane