Sender: lockhart@hub.org
Message-ID: <3768919E.6B9052C8@alumni.caltech.edu>
Date: Thu, 17 Jun 1999 06:11:42 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
MIME-Version: 1.0
To: t-ishii@sra.co.jp
CC: phd2@earthling.net, "'Oleg Bartunov'" <oleg@sai.msu.su>,
	"'hackers@postgresql.org'" <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem
References: <199906170053.JAA08805@ext16.sra.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> > SQL_TEXT ... repertoire must contain:
> > 1) Every character that is used in the SQL language itself (this is
> > the part I remembered), and
> > 2) Every character that is included in *any other character set*
> > supported by the SQL implementation (Postgres).
> > This second requirement is presumably to enable text handling of
> > multiple character sets, but would seem to put severe restrictions on
> > how we would implement things. Or can it act only as a placeholder,
> > allowing us to define new character sets as different types in
> > Postgres? Otherwise, we would have to retrofit capabilities into
> > SQL_TEXT anytime we defined a new character set??
> I don't think so. 2) can be read as:
> Any other character set must contain every character included in
> SQL_TEXT.

Here is the text from the July, 1992 SQL92 draft standard:

         The <implementation-defined character repertoire name>
SQL_TEXT
         specifies the name of a character repertoire and implied
form-of-
         use that can represent every character that is in <SQL
language
         character> and all other characters that are in character
sets
         supported by the implementation.

and later in the same doc:

         11)The character set named SQL_TEXT is an
implementation-defined
            character set whose character repertoire is SQL_TEXT.

I'm reading this to say that SQL_TEXT must contain the union of all
characters in the character sets in the implementation, rather than an
intersection between that union and the characters required by the SQL
language itself.

But I'm not really sure what they mean by this, or whether it is a
problem or not. Clearly different character sets and collations can be
mixed only when that can preserve meaning, so saying that SQL_TEXT has
a repertoire which contains ASCII characters and Japanese characters
doesn't seem to help much.

So istm that "SQL_TEXT" might be just a container class for all
characters in the installation, which still doesn't make complete
sense to me wrt a Postgres implementation.

                      - Tom

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California