From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | peter_e(at)gmx(dot)net |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, barry(at)xythos(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: OCTET_LENGTH is wrong |
Date: | 2001-11-24 00:32:22 |
Message-ID: | 20011124093222Y.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > Yes. Consider you have UNICODE database and want to sort by French or
> > whatever LATIN locale.
> >
> > SELECT * FROM t1 ORDER BY convert(text_column,'LATIN1');
> >
> > would be the only way to accomplish that.
>
> I don't think so. The sort order is independent of the character
> encoding, and vice versa. It must be, because
>
> 1) One language can be represented in different encodings and should
> obviously still sort the same.
>
> 2) One encoding can serve for plenty of languages, which all sort
> differently.
I assume you are talking about the concept of SQL92/99's COLLATE
syntax. But I just talked about what we could do in 7.2 which
apprarently does not have the SQL92's COLLATE syntax.
BTW,
> I don't think so. The sort order is independent of the character
> encoding, and vice versa. It must be, because
This seems different from SQL's CREATE COLLATION syntax.
>From SQL99's CREATE COLLATION definition:
CREATE COLLATION <collation name> FOR
<character set specification>
FROM <existing collation name>
[ <pad characteristic> ]
So it seems a collation depends on a character set.
--
Tatsuo Ishii
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2001-11-24 00:33:17 | Re: OCTET_LENGTH is wrong |
Previous Message | Tom Lane | 2001-11-23 23:55:23 | RPMs and regression tests (was Re: v7.2b3 packaged...) |