| From: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> | 
|---|---|
| To: | Hannu Krosing <hannu(at)trust(dot)ee> | 
| Cc: | Milan Zamazal <pdm(at)debian(dot)cz>, hackers(at)postgreSQL(dot)org | 
| Subject: | Re: [HACKERS] Implications of multi-byte support in a distribution | 
| Date: | 1999-09-02 15:03:00 | 
| Message-ID: | 37CE91A4.5B065286@alumni.caltech.edu | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
> > Each encoding/character set can behave however you want. You can reuse
> > collation and sorting code from another character set, or define a
> > unique one.
> Is it really inside one postmaster instance ?
> If so, then is the character encoding defined at the create table /
> create index process (maybe even separately for each field ?) or can I 
> specify it when sort'ing ?
Yes, yes, and yes ;)
I would propose that we implement the explicit collation features of
SQL92 using implicit type conversion. So if you want to use a
different sorting order on a *compatible* character set, then (looking
up in Date and Darwen for the syntax...):
'test string' COLLATE CASE_INSENSITIVITY
becomes internally
case_insensitivity('test string'::text)
and
c1 < c2 COLLATE CASE_INSENSITIVITY
becomes
case_insensitivity(c1) < case_insensitivity(c2)
- Thomas
-- 
Thomas Lockhart				lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 1999-09-02 15:03:54 | Re: [HACKERS] Odd problem with pg_class ... | 
| Previous Message | Tom Lane | 1999-09-02 14:55:29 | Re: [HACKERS] Odd problem with pg_class ... |