From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, 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-26 07:50:40 |
Message-ID: | 3C01F450.3C6577CB@tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut wrote:
>
> Tatsuo Ishii writes:
>
> > > 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.
>
> I see. But that really doesn't have anything to do with reality. In
> fact, it completely undermines the transparency of the character set
> encoding that we're probably trying to achieve.
COLLATION being independent of character set is a separate problem
from COLLATION being _defined_ on character set - without a known
character set I can't see how you can define it.
i.e. "COLLACTION for any 8-bit charset" just does not make sense.
-----------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2001-11-26 08:45:48 | Re: OCTET_LENGTH is wrong |
Previous Message | Joe Conway | 2001-11-26 07:19:54 | Re: bytea/ODBC/MSAccess issue |