Quoth Norman Gray <nor...@astro.gla.ac.uk>, on 2010-12-26 19:11:02 +0000: > > A UNIQUE specifier on a column creates one UNIQUE constraint on > > exactly that column. UNIQUE specifiers on multiple columns are > > unrelated. You may specify a multi-column UNIQUE constraint by > > declaring it separately (and not as part of any column specification). > > Thanks for that. That's what I eventually worked out (as I noted).
Hmm! There's something ironic about that in that it wasn't entirely clear to me that you'd understood it. :-) Note that there is no semantic distinction that completely separates "table constraints" from "column constraints" in the case of UNIQUE. That is, unless I am very much mistaken, CREATE TABLE t (a ... UNIQUE) and CREATE TABLE t (a ..., UNIQUE (a)) are exactly equivalent and the former is an abbreviation for the latter. The text in the CREATE TABLE page that discusses this says, in the section on column definitions: | The other constraints - NOT NULL, CHECK, UNIQUE, PRIMARY KEY and | FOREIGN KEY constraints - impose restrictions on the tables data, and | are are described under SQL Data Constraints below. It seems pretty clear to me that placing one of these in a column definition creates a constraint on only that column, just like each of the other column constraint specifiers, but I agree that it could be more explicitly written out. (Especially since CHECK is actually a special case; I think the implicit equivalence with table constraint ignores the column name entirely and it's more a semantic convenience for someone reading the SQL.) (Backseat authoring: I would tend to write the definitions out as approximate reductions to CHECK, CREATE UNIQUE INDEX, and/or FOREIGN KEY, but I don't have the resources to submit a full proposal right now...) ---> Drake Wilson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
