From: | Sandor(dot)Vig(at)audi(dot)hu |
---|---|
To: | sszabo(at)megazone23(dot)bigpanda(dot)com |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-bugs(at)postgresql(dot)org |
Subject: | Vá: Va: [BUGS] Va: [BUGS] Bug #519: Bug in order b y clausule |
Date: | 2001-11-30 09:54:11 |
Message-ID: | 1F4D693B8F81D3119AD80008C75B7BB40165B5E4@gs0011.audi.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> > So, it is still a mystery for me....
> You probably need the locale for sorting the single character letters
> but you don't want the collation values of the multiple character ones.
> I think you're probably going to need to get an alternate locale
> file but I'm not sure what's involved in that outside of postgres.
> For postgres you'd need to dump, initdb under the new locale and restore
> probably.
[Vig, Sandor]
I'll overwrite the hu_HU collocation file with the en_EN one. It is
NOT
a sollution, it just corrects the problem. Do you guys find it OK,
to
have such an effect? Should we say:
All Hungarian -and other non standard ANSI- users should expect
"order by problems" due the locale settings.?
I suggest to have -at least- a patch for such problem, or a special
postmaster switch, where an alternate collocation file could be
specified. I must work with DB2, and there is a lot of anoing side
effects
with the country selections. f.e.: No codepage translation between
Hungarian and German settings, locale-ized client full with bugs,
etc...
It would be great, not to have these things in Postgresql.
At the end, I want to thank you all for your help. I must say,
Postgresql is still my favourite DBM.
Bye,
Vig Sandor
From | Date | Subject | |
---|---|---|---|
Next Message | pgsql-bugs | 2001-11-30 14:58:29 | Bug #526: Three levels deeply nested SELECT goes wrong |
Previous Message | Alla El Gohary | 2001-11-30 00:11:05 | server hang up |