> > Oh. I was recalling SQL_TEXT as being a "subset" character set which
> > contains only the characters (more or less) that are required for
> > implementing the SQL92 query language and standard features.
> > Are you seeing it as being a "superset" character set which can
> > represent all other character sets??
> Yes, it's my understanding from the section 19.3.1 of Date's book
> (fourth edition). Please correct me if I am wrong.
Yuck. That is what is says, all right :(
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.
afaict (2) pretty much kills extensibility if we interpret that
literally. I'd like to research it a bit more before we accept it as a
requirement.
> > I'd propose that we start accumulating a feature list, perhaps ordering
> > it into categories like
> >
> > o required/suggested by SQL9x
> > o required/suggested by experience in the real world
> > o sure would be nice to have
> > o really bad idea ;)
>
> Sounds good. Could I put "CREATE CHARACTER SET" as the first item of
> the list and start a discussion for that?
>
> I have a feeling that you have an idea to treat user defined charset
> as a PostgreSQL new data type. So probably "CREATE CHARACTER SET"
> could be traslated to our "CREATE TYPE" by the parer, right?
Yes. Though the SQL_TEXT issue may completely kill this. And lead to a
requirement that we have a full-unicode backend :((
I'm hoping that there is a less-intrusive way to do this. What do other
database systems have for this? I assume most do not have much...
- Thomas