On 2004-11-04 18:42:50 +0100, Alexander Demenshin wrote:
I just want to understand _why_ SQLite uses implicit conversions
Pike strings are defined as strings of 32-bit values. If you expect to store a string in SQLite and read it back exactly as it was, you have to encode it in some way. Using UTF-8 (which is standardized and in wide use) seems to be better than inventing the umpteenth proprietary encoding.
when no other DB module does this,
I haven't checked if there is really no other DB module which does this, but it is possible that these modules are older than wide strings in Pike (I don't remember when wide strings in Pike were introduced, but I'm fairly sure that at least some database modules already existed at that time) and nobody bothered to update them, or that the author of the module didn't think about what would happen if you tried to store a wide string in a database. Or they did think about it and decided that that should be decided by the application.
I'll have to check what the Oracle module does. I think it should do implicit conversions for varchar2 and clob fields, but not for blob fields (does it matter for numeric fields?)
If core team or module author against my proposal to add this flag - this is OK, just _tell_ me that in _clear text_, instead of trying to convience me that I am wrong, or at least _prove_ that I am wrong.
I don't understand this. If they are against your proposal why shouldn't they argue their point? Why "shut up, we don't like it" better than "we don't like it, because ..."?
hp