On Sat, Jan 19, 2008 at 03:23:32AM +0700, Lothar Scholz wrote: > IT> Does this really make sense to you? > > Yes the only reason left for a BLOB would be a containing zero byte and > any illegal UTF8 sequence of bytes.
Or wanting to avoid collations that are aware of, say, Unicode normalization, Unicode case transformations, ... Really, a blob of bytes either is TEXT or not, and this distinction can make a huge difference for some operations. > For me it looks like the introduction of the current logic is just for > backward compatibility that embedded 0 characters are not allowed in a > string. For me it looks like a form of string content encoding tagging, with a one-bit content type tag: Unicode vs. arbitrary binary content types. (SQLite also has a collation tag.) Additional typing of octet strings could be really useful, or not. I don't know. Perhaps some users have strings in many different codesets and could use TEXT type variants that include codeset information. But such users can always add such tags as columns to existing tables, or they can convert to UTF-8 (or UTF-16) and live with any lossiness. > IMHO it would be cleaner if we conceptionally only have BLOBS > and check for other datatypes on demand maybe with some caching. > Exactly what TCL is doing it when it assumes everything is a string and > (since version 7.X )we got the cached integer or double values. That would only be true if the <, >, =, <=, >=, <=>, LIKE, GLOB and other such operators behaved exactly the same for all strings regardless of whether they were Unicode strings or blobs. But they don't (or at least, I don't want them to). SQLite does not have a normalization-insensitive string comparison operation/function today, but it might eventually, in which case even the basic string equality/inequality comparison operation will behave differently given TEXT inputs vs. BLOB inputs. Please keep TEXT and BLOB as distinct types, Nico -- ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
