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
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 |