Oh no, not Unicode again

[Frank Schima]

--- Ruslan Zasukhin <sunshine at public.kherson.ua> wrote:
> -- Classic still important ?

Not to me.

>    or Carbon is enough ?

It is good enough. 

>    classic can do Unicode work ?

I don't know but I am doubtful. 

> -- [should] we have the same and only
>             String and VarChar fields
> 
>    with addition of 'encoding' parameter?

This is not good because, as Steve Kellogg was saying, it forces code changes. 

>    although this way looks to be hard for UTF16
> 
> 
> -- or we should get new 2 fields
> 
>             UString
>             UVarChar

I like this but not the name - it is slightly confusing because you already have ULong
and similar types where 'U' stands for Unsigned. Why not UnicodeString and UnicodeVarChar
(also see below)?

>     how other dbs do this ?

-MySQL 4.1 claims UTF-8 support, but I cannot find any other information about it besides
that. 

-PostgreSQL supports UTF-8. It seems that a database is created with a specified
encoding. Furthermore it has a convert() function for converting the encoding of strings
in SQL. Here is a sample from the 7.3 docs:

format:  convert(#string using #conversion_name)
example: convert('PostgreSQL' using iso_8859_1_to_utf_8)
result:  'PostgreSQL' in Unicode (UTF-8) encoding

-Sybase 12.5 supports UTF-16 (they used to support UTF-8 in Sybase 11). They have new
field types for Unicode fields: unichar and univarchar. I believe this is the best
approach for Valentina. This is also a good naming convention for Valentina. Namely
UniString and UniVarChar. 


Best Regards,
Frank


=====
Frank Schima                <mailto:frank-lists at labrecyclers.com>
Lab Recyclers Inc.          <http://www.labrecyclers.com/>
Gaithersburg, MD USA        <http://www.ci.gaithersburg.md.us/>

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/