A very interesting discussion thread! Thanks to everyone who posted for adding to my knowledge.

Bob Cochran

[EMAIL PROTECTED] wrote:

Matt Sergeant <[EMAIL PROTECTED]> wrote:
Perl has no concept of blobs. A scalar variable can be one of:

IV (integer)
UV (unsigned integer)
NV (double)
PV (string)

so a blob is just a string - but perl carries a length around with it so you can have binary data in there.


SQLite does has a separate BLOB type. But for TEXT types, SQLite still works like Perl and carries around a length so that the string
can have embedded '\000' characters.  I just added a test to the
test suite to verify that this works.

Suppose you do this:

  sqlite3_bind_text(pVm, 1, "abc\000xyz\000pq", 10, SQLITE_STATIC);

If this is part of an INSERT, say, then you will insert a 10-character
string that happens to contain a couple of extra \000 characters.
The statement:

  SELECT length(x) FROM table;

will return 3 because the length() function is counting UTF-8 characters,
not bytes, and it will stop at the first '\000'.  But if you say this:

  SELECT length(cast(x AS blob)) FROM table;

you will get 10, because length() returns the number of bytes in a blob.

Similarly, if you say:

  SELECT quote(x) FROM table;

you will get 'abc' as a reply.  But if you say:

  SELECT quote(cast(x AS blob)) FROM table;

then you will get X'6162630078797A007071' as the result.  So you see,
all 10 bytes of the original string are still there.

So as far as I can tell, both SQLite and Perl are doing exactly what
they ought to be.

--
D. Richard Hipp <[EMAIL PROTECTED]>




Reply via email to