Roger Binns writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 09/23/2011 08:47 AM, David Garfield wrote: > > But that is the point. Strings are generally defined in two ways. > > Either: > > > > 1) a pointer, and count every byte up to but not including a NUL. > > > > 2) a pointer and a length, and count every byte in the specified length. > > You insist on a dichotomy but SQLite supports both conventions > simultaneously. You'll only have some difficulty if you use the second > convention as some builtin functions operate on the first convention, but > your own user defined functions/collations etc can do the right thing.
I insist on the dichotomy because the dichotomy is real. Think about the semantics of honoring NUL as end of string in the data stored by sqlite in the file. And there is a third hybrid model (NUL or count) that is so little used that most people don't recognize it when it is placed in front of them. SQLite's API supports both (mostly). Internally, you must use one or the other (or hideously duplicate code), and SQLite uses the second -- except for some functions (which use the hybrid model). That exception is the bug. > > Internally, SQLite uses counted strings. It should treat NUL as just > > one more character, since it is just one more character. > > It does with the exception of some user defined functions. Correction: with the exception of a number of BUILT IN functions. sqlite3_value_*() and sqlite3_result_*() are fully capable of using the counted model, and have the same shortcuts for the NUL-terminated model. > > ... user's database ... > > The same database can be populated by many different programs, and you > should really distinguish between users and developers - sometimes they are > the same person and sometimes not. Eg whose database is the one used by > Chrome and Firefox? In this case, by "user" I meant the user of SQLite API, which is in fact a developer. > > Actually, I guess I am more concerned with the "shell". > > The shell is not a formal part of SQLite. It doesn't have the same level of > testing or backwards/forwards compatibility requirements. It is still > completely open code with no restrictions on how it operates so you can > modify the code to do whatever you want. > > > I use blob > > columns that are partly text and would like to have the text portions > > at least be visible. > > You cannot display bytes as text unless you know the encoding. There is > nothing stopping you from altering the shell to do this, adding a hexdump > output mode, adding a user defined function etc. Of course, the SQLite shell does it anyway. So "cannot" is not really correct. > The SQLite shell isn't particular well structured for easy developer > extension. I've seen that... ouch. > My Python SQLite wrapper includes a compatible shell that is > easy to augment and extend: And your python wrapper is probably implemented using the counted string form exclusively. :-) > http://apidoc.apsw.googlecode.com/hg/shell.html > > Roger > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk59DPMACgkQmOOfHg372QRh4gCdE+pNpGL7GG3FD9YVA161JdZj > gYYAn2lrpRpKsNerKWOv6o47EH0AL/Jf > =BPPC > -----END PGP SIGNATURE----- > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
