On 12/21/16, Jens Alfke <j...@mooseyard.com> wrote: > >> On Dec 21, 2016, at 11:49 AM, Richard Hipp <d...@sqlite.org> wrote: >> >>> [Can] a column result value from a virtual >>> table can have a lifespan that outlives the table’s current iteration, >>> i.e. >>> after the next call to reset(). >>> >> >> You mean sqlite3_reset()? No. > > Oops, not “reset”; I was mixing up the name with one of my internal > functions. Sorry! > > The lifespan I’m talking about is the data of the current table row being > processed by the SELECT, which is where the blob column value comes from > that my virtual table is parsing. I’d like to be able to hand out internal > pointers into that blob via sqlite3_result_text. > > The use case is similar to this example from the JSON1 documentation: > SELECT DISTINCT user.name > FROM user, json_each(user.phone) > WHERE json_each.value LIKE '704-%'; > Here would it be valid for the callback that implements ‘json_each.value’ to > return a pointer into the ‘user.phone’ blob? Or does it need to mark it as > transient?
I don't really understand your scenario. So I will suggest that you play it safe and mark it as SQLITE_TRANSIENT. SQLITE_TRANSIENT will always work. SQLITE_STATIC might be slightly faster (or the difference may be lost in the noise - have you measured?) but SQLITE_STATIC might also lead to use-after-free errors and other similar problems that can be difficult to reproduce and track down. -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
