Re: WIP patch: Collation support - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP patch: Collation support
Date
Msg-id 14708.1222092230@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP patch: Collation support  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: WIP patch: Collation support  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> The first thing that we see is that the COLLATE keyword means different 
> things, so it's probably best to change that into:

> CREATE DATABASE <name> WITH LC_COLLATE=<locale name> LC_CTYPE=<locale name>

> in the stripped-down version. Then we need a way to map the 
> stripped-down syntax into the one in the original patch. That's just a 
> matter of looking up the collation in the pg_collation catalog with the 
> right LC_COLLATE and LC_CTYPE.

It seems to me that in an installation using libc-based collation
support, the collation names are likely to be the same as allowed values
of LC_COLLATE anyway.  So inventing different keywords doesn't really
seem necessary.

What might be sensible to ask is whether it is ever actually reasonable
for LC_COLLATE and LC_CTYPE to have different settings.  If we were
willing to enforce that they be the same, we could reduce this to just
the standard syntax COLLATE=something and be done with it.  Not being
much of a user of anything except C locale, I might be the wrong person
to opine on this; but it seems to me that having them different is far
more likely to be a mistake than desirable.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: [patch] fix dblink security hole
Next
From: Tom Lane
Date:
Subject: Re: [patch] fix dblink security hole