On 2/3/20, Dominique Devienne <ddevie...@gmail.com> wrote:
> On Sun, Feb 2, 2020 at 12:50 AM Richard Hipp <d...@sqlite.org> wrote:
>
>> On 2/1/20, Thomas Kurz <sqlite.2...@t-net.ruhr> wrote:
>> >
>> > create table x (x integer check (typeof(x) == 'integer'));
>> > insert into x values ('1');
>> >
>> > --> will pass in future versions???
>>
>> I think that is what it means. yes.
>
> Wow... I haven't caught up on this thread, but that's really really bad
> IMHO,
> and would consider that a serious regression. I've been enforcing
> "strong-typing",
> (or "inflexible-typing" if you prefer Richard) for many schemas, and
> the fact we can
> no longer do that would be a real shame. I wonder where this is coming
> from... --DD
This is the SQL:
CREATE TABLE t1(x INT CHECK(typeof(x)=='integer'));
INSERT INTO t1(x) VALUES('123');
You say that you want to prevent the use of the string literal '123'
for inserting into the integer field x. That will no longer be
possible in SQLite beginning with 3.32.0 (assuming the change
currently on trunk goes through.)
But, why do you want to do that? How do you prevent the use of a
string literal to initialize an integer field in MySQL, PosgreSQL, SQL
Server, and Oracle - all of which accept and run the SQL above
(without the CHECK constraint) with no errors?
If your goal is to prevent an actual string from being stored in the
"x" column, then the legacy CHECK constraint still works for that.
The following insert still fails:
INSERT INTO t1(x) VALUES('xyzzy');
But, you will no longer be allowed to prevent the type coercion that
forces the '123' value into an integer 123, I think. At least, I do
not see a way to do that on trunk right now.
I have put a "Pre-release Snapshot" of the latest code on the Download
page to try to make it easier for people to try out this new change.
--
D. Richard Hipp
d...@sqlite.org
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
