D. Richard Hipp wrote: > There is good reason for this, actually.
But I'm not sorting, nor doing a < or > comparsion. In fact none of this has to do with comparison at all, but *identity*, which is a much simpler test. Are you really arguing that there are situations where a string value (in arbitrary encoding -- whatever is stored) and a blob cannot be tested for equality unambiguously? > The second point is that TEXT can be converted from UTF-8, UTF-16be, > and UTF-16le. Sure. But as I mentioned it's UTF-8. Certainly it can't be a problem to compare a blob and a string for bytewise equality? Do you have a real world use case for a situation where this actually causes unwanted behavior? Because: > SQLite takes the approach of always making every BLOB larger than > every TEXT string. That is simple and unambiguous. ...but it's a disaster for people like me trying to actually take advantage of the manifest typing feature. I have an (IMHO really pleasing) API that looks like this: sqlite.exec(db, "select * from X where Y = ?", ...bind params...) This obviously presumes that types are convertable at runtime, which in SQLite they *mostly* are; I can pass in the string "12" and get a valid comparison to an integer or real value, etc... But I *can't* know when binding the parameter whether the context in which it will be used is a blob or a string. So what I do is use bind_blob() universally for all string objects. I was led to believe by your documentation on manifest typing and by analogy to your automatic numeric conversions that this sort of conversion was legal. But if that does not work, then this whole API design is shot. I'd have to expose the *explicit* typing of all the values to the user-level API, so they can make the call as to whether to query for a blob or a string. That seems like a mess to me, and very much *out* of keeping with the manifest typing philosophy. Seriously: what's wrong with just (1) converting a string to a blob by exposing the literal byte in whatever encoding it was stored in, and (2) converting a blob to a string by interpreting the bytes literally in the current "pragma encoding" environment? Sure, the user can shoot herself in the foot with that, but it works unambiguously in the only sane case: where the user-side string environment and the database schema are written to use the same encoding. Do you have any other suggestions, or is the clean/simple API choice above just not something you want to suppot with SQLite? It seems like many other language bindings are going to have the same issue... I think what I'll have to do in the interrim is default to bind_text() instead of bind_blob(). Does that work if the data has embedded nuls? Also, can you be more specific about exactly why you made this design choice? This seems to me like a situation where simplicity of implementation (punting on the issue of comparing strings and blobs) got mixed up with simplicity of design (making user-visible type conversion as automatic and error-proof as possible). I've hit that on a bunch of occasions with Nasal, and sometimes it helps to step back a bit and look at the problem from the user's perspective. Andy ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
