From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
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:41:44 |
Message-ID: | 20010215104144E.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > Tom Lane writes:
> >> We now have defenses against running a non-LOCALE-enabled backend in a
> >> database that was created in non-C locale. Shouldn't we likewise
> >> prevent a non-MULTIBYTE-enabled backend from running in a database with
> >> a multibyte encoding that's not SQL_ASCII? Or am I missing a reason why
> >> that is safe?
>
> > Not all multibyte encodings are actually "multi"-byte, e.g., LATIN2. In
> > that case the main benefit is the on-the-fly recoding between the client
> > and the server. If a non-MB server encounters that database it should
> > still work.
>
> Are these encodings all guaranteed to have the same collation order as
> SQL_ASCII?
Yes & no.
>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.
--
Tatsuo Ishii
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2001-02-15 01:42:44 | Re: Shouldn't non-MULTIBYTE backend refuse to start in MB database? |
Previous Message | Brook Milligan | 2001-02-14 23:18:57 | undocumented parts of SPI |