Even though the spec doesn't allow it, SQLite actually accepts multiple table constraints without intervening commas, just like column constraints. Like this:
CREATE TABLE test (id INTEGER, name TEXT, PRIMARY KEY (id) UNIQUE(name))
There are enough examples of this in the wild that I suspect it should be supported.
The approach I've taken is to treat every constraint independently. I've seen examples like this:
CREATE TABLE test (id INTEGER, name TEXT, CONSTRAINT cname PRIMARY KEY (id) UNIQUE(name))
which I think should be interpeted thus:
CREATE TABLE test (id INTEGER, name TEXT, CONSTRAINT cname PRIMARY KEY (id), UNIQUE(name))
It's not really ideal, but is peferable to the alternative (which is that every constraint in every dialect would have to be multiple, including ALTER TABLE ADD CONSTRAINT ..., which I rejected because:
It would do too much violence to the rest of the code,;
It doesn't have any benefit in SQLite which doesn't let you alter constraints anyway.
I don't think this should mean anything:
CREATE TABLE test (id INTEGER, name TEXT, CONSTRAINT pname PRIMARY KEY (id) CONSTRAINT uname UNIQUE(name))
so I've suppressed looking for another CONSTRAINT keyword on subsequent clauses.
Even though the spec doesn't allow it, SQLite actually accepts multiple table constraints without intervening commas, just like column constraints. Like this:
There are enough examples of this in the wild that I suspect it should be supported.
The approach I've taken is to treat every constraint independently. I've seen examples like this:
which I think should be interpeted thus:
It's not really ideal, but is peferable to the alternative (which is that every constraint in every dialect would have to be multiple, including
ALTER TABLE ADD CONSTRAINT ...
, which I rejected because:I don't think this should mean anything:
so I've suppressed looking for another
CONSTRAINT
keyword on subsequent clauses.