Re: [sqlite] c-api document suggestion

2011-09-23 Thread Tim Streater
On 23 Sep 2011 at 11:18, Mirek Suk wrote: > Dne 23.9.2011 4:41, Igor Tandetnik napsal(a): >> 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

Re: [sqlite] c-api document suggestion

2011-09-23 Thread Igor Tandetnik
Mirek Suk wrote: > I just find entire nul handling in SQLite strange. it's C API why not > expect C (that is nul terminated) strings. Because some people do want to store strings with embedded NULs, for various reasons. If you don't, just pass -1 for length and be done with

Re: [sqlite] c-api document suggestion

2011-09-23 Thread Simon Slavin
On 23 Sep 2011, at 11:18am, Mirek Suk wrote: > I just find entire nul handling in SQLite strange. it's C API why not expect > C (that is nul terminated) strings. That's more or less the problem: C expects 0x00 termination. But SQLite3 is written to support UTF-8 and UTF-16 strings of

Re: [sqlite] c-api document suggestion

2011-09-23 Thread Mirek Suk
Dne 23.9.2011 4:41, Igor Tandetnik napsal(a): Mira Suk 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

Re: [sqlite] c-api document suggestion

2011-09-22 Thread Igor Tandetnik
Mira Suk 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

Re: [sqlite] c-api document suggestion

2011-09-22 Thread Mira Suk
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. Igor Tandetnik 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

Re: [sqlite] c-api document suggestion

2011-09-21 Thread Sean Pieper
). -sean -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Richard Hipp Sent: Wednesday, September 21, 2011 12:23 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] c-api document suggestion On Wed, Sep 21, 2011 at 3:0

Re: [sqlite] c-api document suggestion

2011-09-21 Thread Richard Hipp
On Wed, Sep 21, 2011 at 3:05 PM, Sean Pieper wrote: > There's an apparent inconsistency in the behavior of sqlite3_bind_text and > sqlite3_prepare_v2. > If the user supplies the length of the argument rather than using -1, > bind_text expects that this length exclude the

Re: [sqlite] c-api document suggestion

2011-09-21 Thread Pavel Ivanov
> If the user supplies the length of the argument rather than using -1, > bind_text expects that this length exclude the null termination, whereas > prepare apparently expects it to include the null termination. Can I challenge you in that this conclusion is wrong? Everywhere in the development

Re: [sqlite] c-api document suggestion

2011-09-21 Thread Igor Tandetnik
On 9/21/2011 3:05 PM, Sean Pieper wrote: There's an apparent inconsistency in the behavior of sqlite3_bind_text and sqlite3_prepare_v2. If the user supplies the length of the argument rather than using -1, bind_text expects that this length exclude the null termination, You can include the

[sqlite] c-api document suggestion

2011-09-21 Thread Sean Pieper
There's an apparent inconsistency in the behavior of sqlite3_bind_text and sqlite3_prepare_v2. If the user supplies the length of the argument rather than using -1, bind_text expects that this length exclude the null termination, whereas prepare apparently expects it to include the null