I can also imagine a day when
PRAGMA without_rowid_by_default = 1;
will cause tables created subsequently to lack implicit rowid columns.
It'd be easier to enable that if the selection of columns for the
b-tree index were less consequential than requiring a PRIMARY KEY with
its attendant implied unique constraint.
To make that feasible would require a decent default column selection
when there isn't a primary key. My proposal would be to take the
first of the following at first INSERT time:
- first index declared on the table
- first UNIQUE constraint declared on the table
- first column declared UNIQUE with a column constraint
The theory being that without syntax for defining a non-unique index
at table creation time, the schema author's best chance to implicitly
specify the primary b-tree index is with the first index created
before the first insert. Whereas if the schema author has any unique
constraints then the ones where they get to pick the declaration order
should be most preferred for this purpose (the schema author may not
get to pick column declaration order).
And perhaps SQLite3 should copy MySQL's syntax for declaring
non-unique primary b-tree index:
CREATE TABLE ... (..., INDEX USING BTREE (<column-list>));
This also might set the stage for adding hash tables as b-trees where
the key is derived by calling a UDF:
CREATE TABLE ... (..., INDEX USING BTREE (udf(<column-list>));
Nico
--
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
