On Thu, May 19, 2011 at 4:22 PM, Pavel Ivanov <paiva...@gmail.com> wrote:
>> Is there a rationale for allowing such statements or is that an effect
>> of the 'Lite' nature? (Note: I'm not complaining, just asking.)
>
> I believe that's an effect of the "typeless" design. As SQLite doesn't
> have strict type names for columns it accepts pretty much anything for
> that. So in your case it thinks that type of first column is "CHAR
> COLLATE NOCASE" and for second "INTEGER DEFAULT 1". What do those type
> names mean is up to you. :)
Not really, it seems to be an effect of the way the column constraint
grammar rules are written:
carg ::= CONSTRAINT nm ccons.
carg ::= ccons.
ccons ::= DEFAULT term(X). {sqlite3AddDefaultValue(pParse,&X);}
ccons ::= DEFAULT LP expr(X) RP. {sqlite3AddDefaultValue(pParse,&X);}
ccons ::= DEFAULT PLUS term(X). {sqlite3AddDefaultValue(pParse,&X);}
ccons ::= DEFAULT MINUS(A) term(X). {
...
}
ccons ::= DEFAULT id(X). {
...
}
...
ccons ::= NULL onconf.
ccons ::= NOT NULL onconf(R). {sqlite3AddNotNull(pParse, R);}
ccons ::= PRIMARY KEY sortorder(Z) onconf(R) autoinc(I).
{sqlite3AddPrimaryKey(pParse,0,R,I,Z);}
ccons ::= UNIQUE onconf(R). {sqlite3CreateIndex(pParse,0,0,0,0,R,0,0,0,0);}
ccons ::= CHECK LP expr(X) RP. {sqlite3AddCheckConstraint(pParse,X.pExpr);}
ccons ::= REFERENCES nm(T) idxlist_opt(TA) refargs(R).
{sqlite3CreateForeignKey(pParse,0,&T,TA,R);}
ccons ::= defer_subclause(D). {sqlite3DeferForeignKey(pParse,D);}
ccons ::= COLLATE ids(C). {sqlite3AddCollateType(pParse, &C);}
However, I'm not sure how to write this such that there can be only
one of those constraints of which there should be just one but without
then imposing ordering on those constraints. IMO there's no need to
fix this.
Nico
--
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
