Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem
От | Thomas Lockhart |
---|---|
Тема | Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem |
Дата | |
Msg-id | 3768919E.6B9052C8@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem (Tatsuo Ishii <t-ishii@sra.co.jp>) |
Список | pgsql-hackers |
> > 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
В списке pgsql-hackers по дате отправления: