Speaking of type string lifetime, what about pointer lifetime management?
I think you've overlooked the pointer lifetime problem for
sqlite3_result_pointer(C,P,T). This form, unlike the blob form, lacks the
destructor callback for cleanup when SQLite determines the scope of the
last statement using a copy of the pointer value has exited. Your use case
appears to presume that a virtual table is managing the pointer object.
Either that or this mechanism is only otherwise used for global pointer
variables. Is there another way for the host application to be notified
that the last statement using the pointer value has exited scope?
> On 7/17/17, Keith Medcalf <[hidden email]> wrote:
> > Also, a question. sqlite3_bind_pointer(C, P, T) and
> > sqlite3_value_pointer(C, P, T) indicates that T should be a "static
> > Does this mean of type SQLITE_STATIC and that it cannot be a string
> > on the stack (ie, an SQLITE_TRANSIENT), or is a copy made of the string
> > value (ala SQLITE_TRANSIENT) for future use?
> No copy is made of the string. SQLite merely keeps a pointer. If the
> memory that holds the string is deallocated or reused for some other
> purpose, bad things will happen.
> > ---
> > Life should not be a journey to the grave with the intention of arriving
> > safely in a pretty and well preserved body, but rather to skid in
> > in a cloud of smoke, thoroughly used up, totally worn out, and loudly
> > proclaiming "Wow! What a Ride!"
> > -- Hunter S. Thompson
> > _______________________________________________
> > sqlite-users mailing list
> > [hidden email] > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > >
> D. Richard Hipp
> [hidden email] > _______________________________________________
> sqlite-users mailing list
> [hidden email] > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >