That analogy is faulty. The case is rather the choice between <simple straightforward method> and <more complex method>. If the <more complex method> exists, one will think it must do that for a reason.
Not really. I can use read() or readv() in C - both have advantages and disadvantages, /.../
Now you're making the same faulty analogy again, since, as you so clearly points out, in that case each alternative has _both_ advantages _and_ disadvantages. Sorry, but I won't make another attempt to get my point across on this.
There is no set policy in sqlite too. In version 3, it is stated that sqlite will treat any [text] string sent as UTF8 encoded (comparisons etc), but it won't check that it is correct UTF8 encoding or not, thus allowing any encoding that user want to use.
Imho that's about as set as a policy can get without getting anal about it.
Tell me, what do comparisons etc do when they come across invalid UTF8 sequences? Is the recovery procedure well defined?
/.../ Thus, impiclit conversion applied by SQLite module restricts possible applications.
Indeed it does. Ok, that's also a valid point for a flag to turn it off, in case one really wants to abuse the db that way. Just out of curiosity, is that what you're going to do in your application?
Another interesting question: Do SQLite also provide data types for octet sequences that don't imply UTF8 encoding?
/.../ Actually, you can't do much at all through the Sql.Sql interface without knowing the database you're connected to, since so many details differ anyway.
That's why I am against implicit conversions at all, regardless of module, if this module communicates with something that is external to Pike (files, DBs, sockets, etc).
I'm sorry, but I completely fail to understand the "that's why" between the differing details in the db backends and this conclusion.