Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem
От | Thomas Lockhart |
---|---|
Тема | Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem |
Дата | |
Msg-id | 37651B4F.F3B0B6F7@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem (Tatsuo Ishii <t-ishii@sra.co.jp>) |
Ответы |
Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem
|
Список | pgsql-hackers |
> This seems to be a little bit different from the standard. First, > SQL_TEXT is not equal to ascii. It's a subset of ascii. Yes, sorry. I was lazy in my posting. > Second, the > default charset for char and varchar might be implemenation dependent, > not neccesarily limited to SQL_TEXT. The only requirement is the > charset must contain the repertoire SQL_TEXT has. I think any charsets > including ascii I've ever seen satisfies the requirement. Yow! I certainly misremembered the definition. Date and Darwen, 1997, point out that the SQL implementation *must* support at least one character set, SQL_TEXT, whose 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?? > Third, the > standards says nothing about locale. You are referring to the Unix-style system support for "locale"? Certainly the NCHAR and character set support in SQL92 would qualify as locale support in the generic sense... Regards. - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California
В списке pgsql-hackers по дате отправления: