Upon thinking further about this bug, I realize that "correct" behavior is not obvious and might warrant some discussion.
At first, I questioned whether it is appropriate to handle data differently depending upon whether it is typed as BLOB or text. Maybe the edit() function needed a flag for this. However, since this can always be affected, either way, by a type cast, there is no such need. And, given this (effective) option, it seems that treating a text-typed value as being subject to the usual text transformations [a], is perfectly fine, and convenient when they may be needed in order for a user's favored text-editing program to be used. [b] [a. The CRLF <-> "\n" translation is just one such transformation. Character coding could be another. ] [b. On Windows, notepad.exe is always available and "on the PATH", which might make it favored sometimes. But it handles LF as line boundaries very badly. ] I notice an upcoming change to the edit() function, checked in a few days ago, which appears to make the allow-text-transformation decision based upon whether the original input contained any CRLF pairs. I would urge not adopting this approach because it presupposes something not necessarily true, that the input to edit() reliably signifies what should happen to its output. That would not be true if, for example, a single "line" of text without a terminating CRLF were to be edited to become multiples "lines" containing CRLF pairs (which might number one less than "lines".) I submit that a better approach is to embrace the possibility of newline transformation for text-typed edit() input, leaving in the user's hands whether to block that by type-casting to BLOB. That is an option that is eliminated with the recent check-in. Best regards, -- Larry _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
