Re: SQL_TEXT (Re: Re: Big 7.1 open items)
От | Thomas Lockhart |
---|---|
Тема | Re: SQL_TEXT (Re: Re: Big 7.1 open items) |
Дата | |
Msg-id | 395590AC.C4E8650C@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: Re: Big 7.1 open items (Thomas Lockhart <lockhart@alumni.caltech.edu>) |
Ответы |
Re: SQL_TEXT (Re: Re: Big 7.1 open items)
|
Список | 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
В списке pgsql-hackers по дате отправления: