| From: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, Gregory Stark <stark(at)enterprisedb(dot)com>, Radek Strnad <radek(dot)strnad(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: WIP patch: Collation support |
| Date: | 2008-09-23 15:12:52 |
| Message-ID: | 48D90774.3070307@sun.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas napsal(a):
> Zdenek Kotala wrote:
>> pg_collation catalog is also important for pg_dump, because system
>> collation names are not compatible over OS and pg_dump output should
>> be portable. pg_collation adds abstract layer which solve this problem.
>
> That's a valid point. We'll still need a way to map OS locale to
> whatever internal names we invent for them, though, so I'm not sure if
> the pg_collation catalog helps much, but just moves the problem
> elsewhere.
It is true. For names we can for example use RFC479 0IANA register)
http://tools.ietf.org/html/rfc4790#section-7
or use UNICODE terminology CLDR.
> The pg_dump output of the CREATE COLLATION statements still
> wouldn't be portable from one OS to another.
>
I don't think so that pg_collation catalog should be dumped (maybe only
with extra switch).
Zdenek
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2008-09-23 15:25:15 | Re: Initial prefetch performance testing |
| Previous Message | Gregory Stark | 2008-09-23 14:38:40 | Re: Initial prefetch performance testing |