On Fri, Jan 10, 2020 at 7:03 PM Richard Hipp <d...@sqlite.org> wrote:
> On 1/10/20, Dominique Devienne <ddevie...@gmail.com> wrote: > > There's no way at all, to know the length of a text column with embedded > > NULLs? > > You can find the true length of a string in bytes from C-code using > the sqlite3_column_bytes() interface. But I cannot, off-hand, think > of a way to do that from SQL. That's what I thought. Which implies length(text_val) is O(N), while length(blob_val) is O(1), something I never quite realized. And this despite both storing the length the same way at the file-format level. That's kind of a gotcha, which might be worth documenting. I'd vote for a lengthof(col) that's always O(1) for both text and blob values, although I'm not holding my breath for it, as I suspect it's unlikely to be added, given its relative low value. I don't disagree with Keith that text shouldn't contain embedded NULLs, and that C-String are by design and definition that way, I was more thinking of the C++ use case of having an std::string with embedded NULLs, which is perfectly OK and common enough, and using a C++ wrapper for SQLite (which typically uses overloading for binding for example), which will insert a text value for that case, using .c_str() + .length() (or .data() + .size(), doesn't matter, ends up the same), leading to the very issue that started this thread (just a guess). The inability to correctly size a value in SQL (and thus a column, via a sum() group by) for text with embedded nulls is quite unfortunate. And the fact length(text_col) is also O(N) is similarly unfortunate. Thus the above idea of an O(1) lengthof(col), as a companion to typeof(col). Thanks, --DD _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
