Re: Re: Big 7.1 open items
От | Thomas Lockhart |
---|---|
Тема | Re: Re: Big 7.1 open items |
Дата | |
Msg-id | 394A3BAF.25622EBE@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: Big 7.1 open items (Michael Robinson <robinson@netrinsics.com>) |
Ответы |
Re: Re: Big 7.1 open items
|
Список | pgsql-hackers |
> "default database character set" idea does not seem to be the solution > for cross-db relations such as pg_database. The only solution I can > imagine so far is using SQL_TEXT. > BTW, I've been thinking about SQL_TEXT for a while and it seems > mule_internal_code or Unicode(UTF-8) would be the candidates for > it. Mule_internal_code looks more acceptable for Asian multi-byte > users like me than Unicode. It's clean, simple and does not require > huge conversion tables between Unicode and other encodings. However, > Unicode has a stronger political power in the real world and for most > single-byte users probably it would be enough. My idea is let users > choose one of them. I mean making it a compile time option. 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?? And, how would you suggest we start tracking this discussion in a design document? I could put something into the developer's guide, or we could have a plain-text FAQ, or ?? 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 ;) - Thomas
В списке pgsql-hackers по дате отправления: