Roger Binns wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/17/2010 07:12 PM, Dan Bishop wrote: > >> Newlines, backslashes, and double quotes can be included literally. The >> only other character you need to worry about is NUL. >> > > Funnily enough I'm busy writing my own quoting routine right now (the source > are Python objects so I can't reuse the one in SQLite). I've written a quoting routine too, in C++. I just truncated strings at the first NUL character because I didn't think that SQLite supported them.
The other special case I remember is floating-point infinity: I used 9.9e999 and -9.9e999 for those. > The only sensible > way I can see of producing a string literal with NUL (which SQLite quite > happily supports) is to output something like: > > CAST(X'43440045' AS CHAR) > You don't have to write it all in hex. You can just do 'CD' || x'00' || 'E' which works because || automatically converts its operands to strings. > Unfortunately the bytes have to be in the same encoding as the database but > when generating this you don't know what the encoding is or will be for a > dump. My suggestion has the same issue: You have to write x'0000' for UTF-16. > The SQLite shell dump command just ignores the NUL onwards silently > losing data. > Even if it didn't interpret the NUL as terminating the string, you'd still have the problem of the NULs themselves being invisible. > I guess the only other alternative is to register a function that does the > blob to string conversion taking into account blob encoding but that will > then only work in SQLites where the function is registered. For this case, I think the simplest approach would be to ignore BLOBs altogether and register a CHR function. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
