Re: [HACKERS] Implications of multi-byte support in a distribution - Mailing list pgsql-hackers

From Thomas Lockhart
Subject Re: [HACKERS] Implications of multi-byte support in a distribution
Date
Msg-id 37CE91A4.5B065286@alumni.caltech.edu
Whole thread Raw
In response to Re: [HACKERS] Implications of multi-byte support in a distribution  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Responses Re: [HACKERS] Implications of multi-byte support in a distribution
List 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@alumni.caltech.edu
South Pasadena, California


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Odd problem with pg_class ...
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Odd problem with pg_class ...