> I'll report the results, for the record.
Okay, for the record, all went well. I re-initialise my PostgreSQL 7.4
database cluster using the following command:
initdb --locale=C --encoding UNICODE
Then, after defining the relevant groups and users, I used pg_restore to
restore my data from a dum
>> C locale and en_* locales give different ordering (at least under Linux).
>> The en_* ordering is case insensitive, and the C locale ordering is case
>> sensitive because it is simply comparing the ASCII codes.
>
> You could use lower/upper to get case insensitive ordering with C locale.
Okay,
> Harry Mantheakis wrote:
> >>Correct. The lesson is, never use locale support for Asian languages
> >>and multibyte encodings including UTF-8.
> >
> >
> > Thank you for your reply - much appreciated.
> >
> > I'm now concerned if and how this will affect ORDER BY query results (and
> > other fun
Harry Mantheakis wrote:
>>Correct. The lesson is, never use locale support for Asian languages
>>and multibyte encodings including UTF-8.
>
>
> Thank you for your reply - much appreciated.
>
> I'm now concerned if and how this will affect ORDER BY query results (and
> other functions) with respe
> Correct. The lesson is, never use locale support for Asian languages
> and multibyte encodings including UTF-8.
Thank you for your reply - much appreciated.
I'm now concerned if and how this will affect ORDER BY query results (and
other functions) with respect to Latin-1 names and words.
I thi
> Hello
>
> I run PostgreSQL 7.4.6 on Linux with a JDBC client.
>
> I initialised my database cluster with the following initdb command:
>
> initdb --locale=en_GB.UTF-8 --encoding UNICODE
>
> I have now discovered that my database cannot distinguish Japanese names or
> words - it throws unique
>> Meanwhile, am I correct in assuming that re-initialising my database cluster
>> with "--locale=C" will solve the problem?
>
> AFAIK it should --- of course you won't get any very intelligent sorting
> or case folding, but at least it can tell the difference between
> different characters ;-).
Harry Mantheakis <[EMAIL PROTECTED]> writes:
> Meanwhile, am I correct in assuming that re-initialising my database cluster
> with "--locale=C" will solve the problem?
AFAIK it should --- of course you won't get any very intelligent sorting
or case folding, but at least it can tell the difference
> Hmm, is that actually the correct spelling of the locale? On my Linux
> box, locale -a says it's "en_GB.utf8". I'm not sure how well initdb can
> verify the validity of a locale parameter, especially back in the 7.4
> branch. It could be that you are actually using a locale that doesn't
> use
Harry Mantheakis <[EMAIL PROTECTED]> writes:
> I run PostgreSQL 7.4.6 on Linux with a JDBC client.
> I initialised my database cluster with the following initdb command:
> initdb --locale=en_GB.UTF-8 --encoding UNICODE
> I have now discovered that my database cannot distinguish Japanese names or
Hello
I run PostgreSQL 7.4.6 on Linux with a JDBC client.
I initialised my database cluster with the following initdb command:
initdb --locale=en_GB.UTF-8 --encoding UNICODE
I have now discovered that my database cannot distinguish Japanese names or
words - it throws unique constraint errors on
11 matches
Mail list logo
