Dne 23.9.2011 4:41, Igor Tandetnik napsal(a):
Mira Suk<mira....@centrum.cz> wrote:
On 9/21/2011 21:22 Igor Tandetnik wrote:
You can include the NUL terminator, if you want it to actually be stored
in the database.
Actually you can't - if you do all SQL string functions will not work.
to be clear -
SELECT TRIM(what ever text column you stored with including null on end of
string)
will not trim that string.
It does work - it removes all whitespace from the end of the string, up to but
not including the first non-whitespace character. Which happens to be NUL. It
follows the spec perfectly, it's your expectations that are wrong.
Note that I didn't say it was wise to store NUL characters as part of the
string - I only said that you could do it if you wanted to. sqlite3_bind_text
takes the length parameter at face value, and stores exactly as many bytes as
you tell it to store. It's up to you to ensure that the values actually make
sense for your application. Garbage in/garbage out and all that.
I just find entire nul handling in SQLite strange. it's C API why not
expect C (that is nul terminated) strings.
man says
"Strings returned by sqlite3_column_text() and sqlite3_column_text16(),
even empty strings, are always zero terminated."
"The values returned by sqlite3_column_bytes()
<http://www.sqlite.org/c3ref/column_blob.html> and
sqlite3_column_bytes16() <http://www.sqlite.org/c3ref/column_blob.html>
do not include the zero terminators at the end of the string. For
clarity: the values returned by sqlite3_column_bytes()
<http://www.sqlite.org/c3ref/column_blob.html> and
sqlite3_column_bytes16() <http://www.sqlite.org/c3ref/column_blob.html>
are the number of bytes in the string, not the number of characters."
If I include my nul does this mean string is my nul terminated or sqlite
appends another one ? is this auto-added null included in size returned
? or not ? are my nuls removed from string size or not ? (there is man
obviously wrong as column_bytes returns size including "zero terminators
at the end of the string" if I set them) => testing how API behaves is
required to produce code due to unclear docs IMHO.
As for non-functioning SQL text functions - David Garfield did some
test. It's some time ago when I found out this does not work as
expected, and yes, I most likely provided invalid sample. Fact is I wont
ever store nul in SQLite database, as I don't trust all SQLite string
functions will respect it.
Maybe as You said, my expectations are wrong, however my expectations
are based on other database engines. if one behaves differently, maybe
it's not just my expectations.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
