Re: Vá: Va: [BUGS] Va: [BUGS] Bug #519: Bug in order b y clausule

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

Sandor(dot)Vig(at)audi(dot)hu writes:
> All Hungarian -and other non standard ANSI- users should expect
> "order by problems" due the locale settings.?

As far as I can see, this is *not* a Postgres bug. If you don't like
the sort order specified by your locale file, you need to choose another
locale file. We're just doing what the locale file says to do.

Depending on what it is you want from the locale features, you might be
able to get the right effect with some combination like LC_COLLATE=C
and LC_CTYPE=hu_HU. Or maybe you should just recompile Postgres with
locale support turned off.

regards, tom lane

On Fri, 30 Nov 2001 Sandor(dot)Vig(at)audi(dot)hu wrote:

> > > 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'm not sure this is true. As far as the system is concerned this is
the correct ordering. ;) If you don't want collation based on your locale
I'd suggest either turning off locale in postgres (see configure
options) or initdb in "C" locale, you don't need to change the system's
collation to do this, just set the locale for the shell that runs initdb.

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

There's been talk about implementing the full SQL character set stuff in
the future which would probably at least limit these problems probably
(it would for example presumably allow you to collate a field you didn't
want to collate via hungarian rules by a different collation).