On Wed, Jul 4, 2012 at 8:06 AM, Igor Tandetnik wrote:
> Nico Williams wrote:
>> SQLite3 also needs to know the identifiers of schema elements at
>> statement prep time. It might be nice to have a variant of
>> sqlite3_prepare_v2() that takes a varargs
On Wed, Jul 04, 2012 at 08:29:33AM -0500, Jay A. Kreibich scratched on the wall:
> On Wed, Jul 04, 2012 at 01:09:01AM -0500, Nico Williams scratched on the wall:
>
> > But this would
> > just be a glorified (if safer) variant of sqlite3_mprintf() -- for
> > apps that allow users to manipulate the
On Wed, Jul 04, 2012 at 09:06:16AM -0400, Igor Tandetnik scratched on the wall:
> Nico Williams wrote:
> > SQLite3 also needs to know the identifiers of schema elements at
> > statement prep time. It might be nice to have a variant of
> > sqlite3_prepare_v2() that takes a
On Wed, Jul 04, 2012 at 01:09:01AM -0500, Nico Williams scratched on the wall:
> But this would
> just be a glorified (if safer) variant of sqlite3_mprintf() -- for
> apps that allow users to manipulate the schema this could actually be
> a good improvement.
The sqlite3_*printf() family
Nico Williams wrote:
> SQLite3 also needs to know the identifiers of schema elements at
> statement prep time. It might be nice to have a variant of
> sqlite3_prepare_v2() that takes a varargs list of parameters which
> must be identifiers, and then have a syntax for
SQLite3 also needs to know the identifiers of schema elements at
statement prep time. It might be nice to have a variant of
sqlite3_prepare_v2() that takes a varargs list of parameters which
must be identifiers, and then have a syntax for referring to
identifier parameters as opposed to value
On 07/04/2012 03:30 AM, Jay A. Kreibich wrote:
On Tue, Jul 03, 2012 at 04:26:42PM -0400, Richard Hipp scratched on the wall:
Actually, you can bind on a DDL statement, but bindings are only valid for
the lifetime of the statement itself, not for the whole lifetime of the
object created by the
Robert Myers wrote:
> DROP TABLE ? would've been useful for me.
Parameters can only appear where literals would be allowed by the syntax. A
table name is not a literal.
--
Igor Tandetnik
___
sqlite-users mailing list
On 7/3/2012 3:26 PM, Richard Hipp wrote:
Igor is correct.
Actually, you can bind on a DDL statement, but bindings are only valid for
the lifetime of the statement itself, not for the whole lifetime of the
object created by the CREATE statement. So doing such bindings are
pointless. And you
On Tue, Jul 03, 2012 at 04:26:42PM -0400, Richard Hipp scratched on the wall:
> Actually, you can bind on a DDL statement, but bindings are only valid for
> the lifetime of the statement itself, not for the whole lifetime of the
> object created by the CREATE statement.
Is that a side-effect
On Tue, Jul 3, 2012 at 4:18 PM, Yuriy Kaminskiy wrote:
> Igor Tandetnik wrote:
> > On 7/3/2012 10:05 AM, Unsupported wrote:
> >> // case 1: exception
> >> //verify(sqlite3_prepare_v2(db, "create trigger updater
> >> update of result on plugins"
> >>
Igor Tandetnik wrote:
> On 7/3/2012 10:05 AM, Unsupported wrote:
>> // case 1: exception
>> //verify(sqlite3_prepare_v2(db, "create trigger updater
>> update of result on plugins"
>> // " begin"
>> // " update mails set kav=case old.result when
>>
On 7/3/2012 10:05 AM, Unsupported wrote:
// case 1: exception
//verify(sqlite3_prepare_v2(db, "create trigger updater update of result on
plugins"
// " begin"
// " update mails set kav=case old.result when 'infected' then ? else
0 end where
Hello.
It looks like I found a bug in sqlite3_step. Here is the sample
code.
#include
#include
#include
#include "sqlite3.h"
#ifdef _DEBUG
#define verify(f) assert(f)
#else
#define verify(f) ((void)(f))
#endif
char const * const fname = "bug.db3";
int cb(void*, int,
14 matches
Mail list logo