>
> For good or bad, check constraints appear to be evaluated before this
>
conversion.
I call that very bad.
On Wed, Mar 20, 2019 at 7:58 AM Shawn Wagner
wrote:
> A manual INSERT demonstrates the same behavior, actually. Using your Tc
> table:
>
> sqlite> insert into Tc values ('12');
>
A manual INSERT demonstrates the same behavior, actually. Using your Tc
table:
sqlite> insert into Tc values ('12');
Error: CHECK constraint failed: Tc
The thing about .import is that, instead of guessing what type each value
it reads is, they're all just bound to an insert statement as strings.
On Sun, 10 Mar 2019 17:04:46 -0400
"James K. Lowden" wrote:
> Why does the .import command cause the CHECK constraint to fail, when
> an ordinary INSERT does not?
On Sun, 10 Mar 2019 14:12:33 -0700
Shawn Wagner wrote:
> The check constraint is probably being evaluated (with t as a string)
>
The check constraint is probably being evaluated (with t as a string)
before any type conversion to match the column affinity is done.
On Sun, Mar 10, 2019, 2:05 PM James K. Lowden
wrote:
> $ sqlite3 db "create table T (t integer not null);"
> $ sqlite3 db "create table Tc (t integer not null
>
$ sqlite3 db "create table T (t integer not null);"
$ sqlite3 db "create table Tc (t integer not null
check(typeof(t) = 'integer'));"
$ echo 1 > dat
$ sqlite3 db ".import 'dat' T"
$ sqlite3 db ".import 'dat' Tc"
dat:1: INSERT failed: CHECK constraint failed: Tc
$
5 matches
Mail list logo
