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

Re: SQL_TEXT (Re: Re: Big 7.1 open items)

From: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
To: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
Cc: pgsql-hackers(at)hub(dot)org
Subject: Re: SQL_TEXT (Re: Re: Big 7.1 open items)
Date: 2000-06-25 04:55:08
Message-ID: 395590AC.C4E8650C@alumni.caltech.edu (view raw or flat)
Thread:
Lists: pgsql-hackers
> > Date says that SQL_TEXT is required to have two things:
> > 1) all characters used in the SQL language itself (which is what I
> > recalled)
> > 2) Every other character from every character set in the 
> > installation.
> Doesn't it say "charcter repertory", rather than character set? I
> think it would be possible to let our SQL_TEXT support every character
> repertories in the world, if we use Unicode or Mule internal code for
> that.

I think that "character set" and "character repertoire" are synonymous
(at least I am interpreting them that way). SQL99 makes a slight
distinction, in that "repertoire" is a "set" in a specific context of
application.

I'm starting to look at the SQL99 doc. I am going to try to read the doc
as if SQL_TEXT is a placeholder for "any allowed character set", not
"all character sets simultaneously" and see if that works. 

Since there are a wide range of encodings to choose from, and since most
character sets can not be translated to another random character set,
having SQL_TEXT usefully require all sets present simultaneously seems a
bit of a stretch.

I'm also not going to try to understand the complete doc before having a
trial solution; we can extend/modify/redefine/throw away the trial
solution as we understand the spec better.

While I'm thinking about it: afaict, if we have the ability to load
multiple character sets simultaneously, we will want to have *one* of
those mapped in as the "default character set" for an installation or
database. So we might want to statically link that one in, while the
others get loaded dynamically.

                    - Thomas

In response to

Responses

pgsql-hackers by date

Next:From: Adriaan JoubertDate: 2000-06-25 07:17:52
Subject: Re: Re: [HACKERS] Re: Call for port testing on fmgr changes -- Results!
Previous:From: Thomas LockhartDate: 2000-06-25 04:36:13
Subject: Re: [HACKERS] Re: Call for port testing on fmgr changes -- Results!

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