Skip site navigation (1) Skip section navigation (2)

Re: OCTET_LENGTH is wrong

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 (view raw or flat)
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

In response to

Responses

pgsql-hackers by date

Next:From: Tatsuo IshiiDate: 2001-11-24 00:33:17
Subject: Re: OCTET_LENGTH is wrong
Previous:From: Tom LaneDate: 2001-11-23 23:55:23
Subject: RPMs and regression tests (was Re: v7.2b3 packaged...)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group