Additionally, declaring NOT NULL or NULL is ignored. CHECK constraints are honoured. DEFAULT values are ignored.
so CREATE TABLE x(id INTEGER NULL PRIMARY KEY CHECK (id>1000) DEFAULT (-1)); & CREATE TABLE x(id INTEGER NULL PRIMARY KEY CHECK (id>1000)); is CREATE TABLE x(id INTEGER PRIMARY KEY CHECK(id>1000)); This is because an "INTEGER PRIMARY KEY" has a computed default that you cannot override, and the rowid must always be always NOT NULL ... -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı > -----Original Message----- > From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] > On Behalf Of Richard Hipp > Sent: Monday, 12 June, 2017 17:44 > To: SQLite mailing list > Subject: Re: [sqlite] INTEGER PRIMARY KEY > > On 6/13/17, Scott Robison <sc...@casaderobison.com> wrote: > > > > Is it fair to say that the rowid aliasing behavior does not require > > (by design) the incantation "INTEGER PRIMARY KEY" (all three words in > > that order as the "type") as long as the type is INTEGER and the > > constraint PRIMARY KEY appears somewhere in the column's constraint > > list? > > See https://www.sqlite.org/lang_createtable.html#rowid > > CREATE TABLE t(x INTEGER PRIMARY KEY DESC, y, z); > > Columns x *not* a ROWID. Life is complicated. Sorry for the mess. > But we have to preserve backwards compatibility - even with bugs like > this. > > > > -- > > Scott Robison > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users@mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > > > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > 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
