Запросы к БД, опечатки и строгая типизация

[metaclass]

Неоднократно читал истории, типа этой, когда из-за мелкой опечатки убивалась целая таблица данных.

И каждый раз удивляюсь тому, что разработчики СУБД ложат хер на теорию ради экономии на паре символов и псевдолаконичности и что SQL в разных серверах по разному реагирует на ошибки в типах данных.
А вот была бы строгая типизация - большая часть этих запросов ну нихрена бы тайпчекер не прошла.

Кстати, в этом плане полезен Firebird - там разработчики стараются жостко следовать стандартам, вплоть до того, что ломают обратную совместимость при переходе между версиями, если этого требует кошеризация.
Я вот жалею, что у меня почти нет опыта работы с Postgresql и Oracle - было бы очень интересно сравнить подходы на этот счет в разных серверах, а не только Firebird с MSSQL.

Comments

[http://users.livejournal.com/_windwalker_/]

на первый взгляд выглядит как bullshit, ибо id в where не определено, и там должен быть search condition, который вычисляется как true, false or unknown.

Которое, в свою очередь вычисляется через предикат:
<predicate> ::=
<comparison predicate>
| <between predicate>
| <in predicate>
| <like predicate>
| <null predicate>
| <quantified comparison predicate>
| <exists predicate>
| <unique predicate>
| <match predicate>
| <overlaps predicate>

Где я никак в упор не вижу id - 1. Т.е. это либо криворукость самописного парсера SQL, либо навороченность админки 1ц, либо навороченность диалекта SQL от MYSQL.

[inhate.livejournal.com]

А где там написано хоть слово про MySQL ?

[http://users.livejournal.com/_windwalker_/]

ну вот именно в мускуле я сталкивался с вопиющими странностями парсера SQL