Just realized that the attachment was not actually included with the original message. Here's a gist link instead: https://gist.github.com/0x09/445fca08ffb4811eae3ca61f965c7a22 <https://gist.github.com/0x09/445fca08ffb4811eae3ca61f965c7a22>
> On Nov 11, 2019, at 2:08 PM, tab <t...@0x09.net> wrote: > > re: expanded_sql this is a bit different -- while sqlite3_expanded_sql > provides the values interpolated into the statement as text, this patch adds > a function for retrieving them individually from the statement, similar to > the column access functions. e.g: > > /* bind some temporary sqlite3_value* at index 1 */ > sqlite3_bind_value(stmt,1,someval); > > /* retrieve it later */ > sqlite3_value *val = sqlite3_param_value(stmt,1); > > Since the statement necessarily holds onto its bound params it'd be a nice > addition to be able to refer to it here if the application/module needs, vs > maintaining memory/lifetime for those independent of the statement. But it is > more or less just a convenience. > >> On Nov 11, 2019, at 1:24 PM, test user <example.com.use...@gmail.com> wrote: >> >> Wouldn’t your program already know what the values are as it passed them >> over the FFI initially? Why not hold onto that state? >> >> On Mon, 11 Nov 2019 at 17:57, x <tam118...@hotmail.com> wrote: >> >>> Is http://www.sqlite.org/c3ref/expanded_sql.html no use to you? >>> >>> >>> >>> ________________________________ >>> From: sqlite-users <sqlite-users-boun...@mailinglists.sqlite.org> on >>> behalf of tab <t...@0x09.net> >>> Sent: Monday, November 11, 2019 5:26:42 PM >>> To: sqlite-users@mailinglists.sqlite.org < >>> sqlite-users@mailinglists.sqlite.org> >>> Subject: [sqlite] [draft patch] interface for retrieving values of bound >>> parameters >>> >>> Hi all, >>> >>> It'd be handy to be able to retrieve params previously bound to a >>> statement in the C API. Per the advice on the SQLite copyright info page, >>> this is much more of a suggestion than a full patch, though it is >>> functional for binding and retrieving an sqlite_value* (but, for example, >>> there might be further implications not considered here in allowing the >>> contents of aVar to be used directly.) There wouldn't be much value in >>> maintaining a fork for something like this, so I wanted to put that out >>> here on the mailing list to see if it's something that might be considered >>> for mainline. >>> >>> _______________________________________________ >>> sqlite-users mailing list >>> sqlite-users@mailinglists.sqlite.org >>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >>> _______________________________________________ >>> sqlite-users mailing list >>> sqlite-users@mailinglists.sqlite.org >>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >>> >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@mailinglists.sqlite.org >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
