> Pavel Ivanov writes:
> On Wed, Oct 12, 2011 at 11:12 AM, Ivan Shmakov wrote:
[…]
>> Consider, e. g.:
>> sqlite3_value *a
>> = sqlite3_int64_value (1);
>> assert (a != 0);
>> sqlite3_value *b
>> = sqlite3_text_value (-1, "qux");
>> sqlite3_value *c
>> = sqlite3_blob_value
On Wed, Oct 12, 2011 at 11:12 AM, Ivan Shmakov wrote:
> >> Given some way to construct a sqlite3_value wrapping object, I
> >> could instead rely on sqlite3_bind_value () alone, thus
> >> eliminating the necessity of type specifiers in the interface.
>
> > Well, a
> Igor Tandetnik writes:
> Ivan Shmakov wrote:
>> I wonder, is it possible to create sqlite3_value * from scratch
>> from within SQLite library's user code?
> There's a circuitous route that leads there. You can prepare a
> statement of the form "select ?;",
Ivan Shmakov wrote:
> I wonder, is it possible to create sqlite3_value * from scratch
> from within SQLite library's user code?
There's a circuitous route that leads there. You can prepare a statement of the
form "select ?;", bind the parameter with one of sqlite3_bind_*
I wonder, is it possible to create sqlite3_value * from scratch
from within SQLite library's user code?
The idea is as follows. The current dbtriv.c [1] code has a
db_triv_exec_bound () function, used roughly as follows:
/* sqlite3 *db; */
const char *sql
5 matches
Mail list logo