Re: [HACKERS] Implications of multi-byte support in a distribution

From: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
To: t-ishii(at)sra(dot)co(dot)jp
Cc: Hannu Krosing <hannu(at)trust(dot)ee>, Milan Zamazal <pdm(at)debian(dot)cz>, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Implications of multi-byte support in a distribution
Date: 1999-09-03 01:45:53
Message-ID: 37CF2851.8354847B@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> But we can't avoid calling strcoll() and some other codes surrounded
> by #ifdef LOCALE? I think he actually wants is to define his own
> collation *and* not to use locale if the column is ASCII only.

Right. But there would be a fundamental character type which is *not*
locale-aware, and there is another type (perhaps/probably NCHAR?)
which is...

> Ok, what about throwing away #ifdef
> LOCALE? Same thing can be obtained by defining a special callation
> LOCALE_AWARE.

Or moving the locale-aware stuff to a formal NCHAR implementation.
istm (and to Date and Darwen ;) that there is a tighter relationship
between collations, character repertoires, and character sets than
might be inferred from the SQL92-defined capabilities.

> This seems much more consistent for me. Or even better,
> we could explicitly have predefined COLLATION for each language (these
> can be automatically generated from existing locale data). This would
> avoid some platform specific locale problems.

Right. We may already have some of this with the "implicit type
coersion" conventions I introduced in the v6.4 release.

- Thomas

--
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 1999-09-03 02:18:41 Re: [HACKERS] SELECT BUG
Previous Message Tatsuo Ishii 1999-09-03 00:55:17 Re: [HACKERS] Implications of multi-byte support in a distribution