Re: Shouldn't non-MULTIBYTE backend refuse to start in MB database?

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

In response to

Responses

Browse pgsql-hackers by date

  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