At 21:53 24/09/2014, you wrote:
> If the default cannot be represented exactly, its rounding will be the
> least of the difficulties.
Not always: in scientific applications I've had column values default
to plenty of irrational numbers: fractions of pi, sqrt(2.0) etc.
My main gripe is when t
On Wed, 24 Sep 2014 20:53:32 +0100
Nathaniel Trellice wrote:
> > > You are doing CREATE TABLE statements based on text from an
> > > untrusted user? Really?
>
> > My reaction exactly.
>
>
> I'm writing a library so the safety of the input is out of my hands
> and in that of the application
On 24 Sep 2014, at 8:53pm, Nathaniel Trellice wrote:
> Imagine an application writer who's instructed my library to use pi (say) as
> a column's default. When reading the value out of the database, they may want
> to test if the value equals the default
Sorry, but you don't do this with REALs
Hi Richard, James,
> > > * SQL injection attacks;
> > >
> >
> > You are doing CREATE TABLE statements based on text from an untrusted
> > user? Really?
> My reaction exactly.
I'm writing a library so the safety of the input is out of my hands and in that
of the application writers who wor
On Wed, 24 Sep 2014 09:49:36 -0400
Richard Hipp wrote:
> > * SQL injection attacks;
> >
>
> You are doing CREATE TABLE statements based on text from an untrusted
> user? Really?
My reaction exactly.
> > * floating point value rounding in conversion to/from text;
If the default cannot be
On Wed, Sep 24, 2014 at 7:36 AM, Nathaniel Trellice
wrote:
> Dear list members,
>
> I'm trying to set a default value for a column in my "CREATE TABLE"
> statement. I really, really want to bind the default value (using
> sqlite3_bind_*) rather than expressing it in SQL text to avoid the
> follow
On 24 Sep 2014, at 1:33pm, Nathaniel Trellice wrote:
> Without the INSERT call, my test code runs through without crashing.
> Attempting the INSERT call in the shell tool crashes it too. Following your
> advice, the output of the .schema command looks dodgy:
>
> CREATE TABLE test_table (name
I think that the diagrams on http://www.sqlite.org/lang_createtable.html are
the generic parsing and construction rules for "expr" everywhere an "expr" can
be used. The text description further down the page describes restrictions and
usage particular to the CREATE TABLE statement itself.
Und
On Wed, Sep 24, 2014 at 8:33 AM, Nathaniel Trellice
wrote:
> Attempting the INSERT call in the shell tool crashes it too. Following
> your advice, the output of the .schema command looks dodgy:
>
> CREATE TABLE test_table (name TEXT DEFAULT ('joe'), interest TEXT DEFAULT
> (?1));
>
> I'm an SQLi
Hi Simon,
Thanks for the quick reply.
Without the INSERT call, my test code runs through without crashing. Attempting
the INSERT call in the shell tool crashes it too. Following your advice, the
output of the .schema command looks dodgy:
CREATE TABLE test_table (name TEXT DEFAULT ('joe'), in
My guess would be that finalizing the create table statement makes the bound
value go out of scope and thus be unavailable to the insert statement.
Bound values reside somewhere in the internal prepared statement structure and
do not get copied into the database file, even if they happen to be d
On 24 Sep 2014, at 12:36pm, Nathaniel Trellice wrote:
> The example code, below, highlights the problem I'm having. The code creates
> a table with a bound default value for one of the two columns. The statement
> is prepared (no syntax error warning), and the value bound successfully. But
>
12 matches
Mail list logo