- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
create table test(
id integer primary key auto_increment,
d datetime not null
);
insert into test(id) values (1);
-- а сейчас я покажу вам особую уличную магию
select *, d is null, d is not null from test;
select *, d is null, d is not null from test
where d is not null;
select *, d is null, d is not null from test
where d is null; -- WTF?!
select *, d is null, d is not null from test
where d is not null and d is null; -- WTF?!
Все 4 select'а выводят одинаковый результат... MySQL такой MySQL...
P.S. Вставка всякой херни вместо вывода ошибки лечится добавлением STRICT_ALL_TABLES в sql_mode. А вот where с нулевой датой не лечится, видимо, это баг движка.
bormand 17.10.2014 11:33 # +3
Да тут целая кунсткамера! Оказывается, сейчас мускуль еще более-менее юзабельный... Судя по режимам совместимости раньше было еще хуже...
From MySQL 5.0.2 on, the precedence of the NOT operator is such that expressions such as NOT a BETWEEN b AND c are parsed as NOT (a BETWEEN b AND c). Before MySQL 5.0.2, the expression is parsed as (NOT a) BETWEEN b AND c.
Do not perform full checking of dates. Check only that the month is in the range from 1 to 12 and the day is in the range from 1 to 31. This is very convenient for Web applications where you obtain year, month, and day in three different fields and you want to store exactly what the user inserted (without date validation). Before 5.0.2, this was the default MySQL date-handling mode.
Treat || as a string concatenation operator (same as CONCAT()) rather than as a synonym for OR.
inkanus-gray 17.10.2014 12:02 # +3
Как говорил guest, Шрёдингер, мы нашли твоего кота!
3.14159265 17.10.2014 12:03 # 0
guest 18.10.2014 11:48 # −2
guest 17.10.2014 20:22 # −2
Qwertiy 17.10.2014 20:54 # 0
bormand 17.10.2014 22:31 # 0
Qwertiy 17.10.2014 22:39 # +1
PS: Что-то я нахимичил когда писал вопрос...
bormand 17.10.2014 22:49 # +1
- Папа, а стандарт SQL существует?
- Нет сынок, это фантастика.
Lokich 23.10.2014 04:03 # +1
bormand 23.10.2014 05:33 # 0
Да чё тут непонятного - legacy. Либо ломаем совместимость со старым кодом, юзающим нашу базу, либо ломаем совместимость с другими базами (и стандартом). Само собой все мало-мальски взрослые СУБД выбрали первое. И винить их за это нельзя...
А у мускуля свои тараканы - у них вообще был только нетранзакционный движок. И часть отклонений и извращений унаследованы от него.
Lure Of Chaos 21.10.2014 14:39 # 0
DBdev 21.10.2014 17:28 # +1
inkanus-gray 21.10.2014 23:39 # 0