Swaminathan Saikumar wrote:
I didn't have proper knowledge about the UTF8 format, thanks.
I originally meant nvarchar & nchar, which is basically varchar & char
that supports Unicode regardless of the database encoding.
Well, we don't need that when we have UTF8. There could be edge cases
speed wise when you use UCS16 or UCS32 internally but I'm not sure
how well this would justify a new datatype.
The current problem isnt so much with encoding database wise, its more
about collating database cluster wise - which is something not
easily solved when you want to do it according to the SQL spec.
You could work around that with a functional index.
Regards
Tino Wildenhain
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
