On 2018/06/30 12:05 AM, Thomas Kurz wrote:
Indeed, but that option does exist, it's called CHECK constraints
You're clearly right, but from my point of view, it's redundant to say COLUMN xy INTEGER
CHECK type=integer, because "COLUMN INTEGER" already implies that the column is
integer. And, btw, as CHECK already exists, it shouldn't be too complicated to have a
mode where this CHECKing is automatically done//...
I don't disagree, but this means we lose sight of the important point
that, if you distill the problem to just "INTEGER", then sure, it looks
silly, and sure, you can fix it with internal auto-CHECKing, but in
SQLite the type affinity INTEGER stands father to LONGINT, MEDIUMINT,
SMALLINT, INT, BIT, BOOL and possibly a slew of other types that escapes
me now. Some of which will cease to function the same once you bind
INTEGER to a stiff type format. Now you need to start introducing these
as their own types, which means SQLite INTEGER affinity is no longer
feasible. The same holds true for other affinities. It's either a
type-affinity system, or a Type-system, it can't/shouldn't be both.
My problem is rather that SQLite treats a column declared with an invalid type
as NUMERIC. This can lead to problems that aren't quite obvious. COLUMN xy
DOG_CAT_MOUSE should definitely raise an error.
Okay... what about:
COLUMN xy VARCHAR(50)
or
COLUMN xy MEDIUMTEXT
or
COLUMN xy BIT
or
COLUMN xy DECIMAL(5,2)
Should those raise errors? Because to SQLite those are the exact same
gibberish as:
COLUMN xy DOG_CAT_MOUSE(99)
It's either accepting unknown types, or not. There is no middle road.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
