From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
Cc: | peter_e(at)gmx(dot)net, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Shouldn't non-MULTIBYTE backend refuse to start in MB database? |
Date: | 2001-02-15 01:52:57 |
Message-ID: | 422.982201977@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
>> Are these encodings all guaranteed to have the same collation order as
>> SQL_ASCII?
> Yes & no.
Um, I'm confused ...
>> If not, we have the same index corruption issues as for LOCALE.
> If the backend is configued with LOCALE enabled and the database is
> not configured with LOCALE, we will have a problem. But this will
> happen with/without MUTIBYTE anyway. Mutibyte support does nothing
> with LOCALE support.
Can a backend configured with MULTIBYTE and running in non-SQL_ASCII
encoding ever sort strings in non-character-code ordering, even if it
is in C locale? I should think that such behavior is highly likely
for multibyte character sets.
If it can, then we mustn't allow a non-MULTIBYTE backend to run in
such a database, I think.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2001-02-15 01:53:04 | untrusted Pl/tcl? |
Previous Message | Tatsuo Ishii | 2001-02-15 01:42:44 | Re: Shouldn't non-MULTIBYTE backend refuse to start in MB database? |