Re:Be Careful with UUID or GUID as Primary Keys
by flatline on Friday June 09, 2017 @04:20PM
(#14524195)
Remember this is for in-table storage, so it makes a certain amount of sense - this saves a byte over UTF-16 with support beyond the BMP. You have a hard limit on the byte size of the table - how do you determine a priori how much storage a 20 character UTF8 field will consume? The alternatives are to store the value in a clob field or set a hard byte count on the field and let the application or user be surprised when 20 print characters are rejected. I actually don't know how other providers handle in-table Unicode fields, MySQL made some poor choices on naming things at the least.
[ Parent
| on HN ]
Re:Be Careful with UUID or GUID as Primary Keys
by eridius on Friday June 09, 2017 @04:39PM
(#14524354)
At a bare minimum you'd expect it to be something like utf-8bmp for 3-byte storage and utf-8 for 4-byte.
It's historical. When it was implemented 4 byte unicode did not exist.
Now that it does they can not change the names anymore.
It's the same as why windows is stuck with utf-16, because when they implemented it unicode was 2 bytes.
Re:Be Careful with UUID or GUID as Primary Keys
by eridius on Friday June 09, 2017 @07:57PM
(#14525443)
> When it was implemented 4 byte unicode did not exist.
Incorrect. When UTF-8 was invented, it was actually variable up to 6 bytes in length, being capable of representing code points up to U+7FFFFFFF. It was only shortened to 4 bytes in 2003. There is no point in history where UTF-8 was only limited to 3 bytes.
Re:Be Careful with UUID or GUID as Primary Keys
by Dylan16807 on Friday June 09, 2017 @08:22PM
(#14525542)
That doesn't seem right.
The 1998 version of MySQL didn't support unicode at all yet.
Unicode 2.0 introduced UTF-16 in 1996, making the need for non-BMP characters very explicit.
And UTF-8 at the time supported 31-bit code points.