On Thu, Nov 04, 2004 at 08:20:02PM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
If there were a universal way to encode wide chars in normal files
Even in this case we would need a way to differentiate between binary and text files, so the decision would be on the user/application side.
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, but most people use just read(). And most people in Pike, I guess, use Stdio.FILE() without using set_charset(), despite the fact of it's presence there.
I don't agree. There are a lot of things you don't control in Pike.
Yes, I can't control language internals, but I want to control anything beyond it. The way how files/databases are encoded - at least.
still get the work done, just not _precisely_ in the way you might want to do it.
Yes, I can use asm to get my work done, just not precisely as fast as I can do this in Pike or C :)
The reason the other db modules don't do it is that there's no set policy in those db's what the encoding is.
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. Also It won't make any conversions internally, either on input nor output, except for UTF16 interface, which is not in use in SQLite module. Thus, impiclit conversion applied by SQLite module restricts possible applications.
In Informix and Mysql, the policy is defined outside of DB interface, and it is up to user to decide which is in effect and to apply it (yes, it is dynamic), thus, I don't see any reason why it should be different in SQLite.
providing a uniform string encoding behavior. 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).
Regards, /Al