From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | sszabo(at)megazone(dot)bigpanda(dot)com |
Cc: | gearond(at)fireserve(dot)net, pgsql-general(at)postgresql(dot)org |
Subject: | Re: unicode and sorting(at least) |
Date: | 2004-06-24 14:27:24 |
Message-ID: | 20040624.232724.78703361.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> On Wed, 23 Jun 2004, Dennis Gearon wrote:
>
> > This is what has to be eventually done:(as sybase, and probably others do it)
> >
> > http://www.ianywhere.com/whitepapers/unicode.html
>
> Actually, what probably has to be eventually done is what's in the SQL
> spec.
>
> Which is AFAICS basically:
> Allow multiple encodings
> Allow multiple character sets (within an encoding)
Could Please explain more details for above. In my understanding a
character set can have multiple encodings but...
--
Tatsuo Ishii
> Allow one or more collations per character set
> Allow columns to specify character set and collation
> Allow literals in multiple character sets
> Allow translations and encoding conversions (as supported)
> Allow explicit COLLATE clauses to control ordering and comparisons.
> Handle identifiers in multiple character sets
>
> plus some misc things like allowing sets that control the default
> character set for literals for this session and such.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Nolan | 2004-06-24 14:59:58 | Queries not always using index on timestamp search |
Previous Message | Mark Spruill | 2004-06-24 14:19:34 | Re: Dump produces file with new line characters |