Краткий ответ

Если столбец не указан в списке целевых столбцов INSERT, SQL использует его значение по умолчанию, если оно задано. Если значения по умолчанию нет, обычно подставляется NULL; для столбца с ограничением NOT NULL такая вставка завершается ошибкой.

Явно переданный NULL обычно не запускает DEFAULT: это самостоятельное значение, а не пропуск столбца.

Исторический контекст

Возможность не перечислять все столбцы появилась как практичный способ отделить операцию вставки от полной физической структуры таблицы. Значения по умолчанию позволяют базе самостоятельно заполнять служебные поля, а приложениям — не передавать их при каждой вставке.

Такой подход также упрощает развитие схемы: новый nullable-столбец или столбец с DEFAULT может не требовать немедленного изменения всех существующих операций вставки.

Постановка проблемы

При INSERT важно различать три ситуации: столбец не упомянут, столбцу явно передали NULL, либо передали конкретное значение. Смешение этих случаев может привести к неожиданным статусам, пустым атрибутам или ошибкам ограничения целостности.

Особенно опасен INSERT без явного списка столбцов. Тогда значения сопоставляются с целевыми столбцами в порядке, определённом формой оператора и схемой, что делает запрос хрупким при изменении таблицы.

Подробное решение

Рассмотрим минимальный пример:

CREATE TABLE tasks (
    id INTEGER,
    status VARCHAR(20) DEFAULT 'new',
    comment VARCHAR(100)
);

INSERT INTO tasks (id) VALUES (1);
INSERT INTO tasks (id, status) VALUES (2, NULL);

В первой строке status получает значение 'new', потому что столбец пропущен и у него задан DEFAULT. comment получает NULL, поскольку он также пропущен, но значение по умолчанию для него не задано.

Во второй строке status получает именно NULL: явное значение имеет приоритет над DEFAULT. Если status объявить как NOT NULL, такая вставка завершится ошибкой, несмотря на наличие значения по умолчанию.

Если пропущенный столбец имеет NOT NULL без DEFAULT, база не может сформировать допустимую строку и отклоняет операцию. Для вычисляемых или identity-столбцов действуют дополнительные правила конкретной СУБД, поэтому их обычно не указывают в обычном списке вставки.

Надёжная практика — явно перечислять целевые столбцы. Это делает намерение запроса очевидным, защищает от изменения порядка столбцов и позволяет предсказуемо использовать значения по умолчанию.

Ситуация из практики

Сервис сохраняет заявки только с идентификатором и текстом. В таблицу добавили столбец status со значением по умолчанию 'new', но старый запрос вставки его не перечисляет.

Вариант с пропуском status использует DEFAULT и не требует изменения приложения. Это удобно, но разработчикам нужно проверить, что значение по умолчанию действительно соответствует бизнес-правилам.

Вариант с явной передачей 'new' делает поведение заметным в коде, но дублирует правило схемы. Если бизнес-правило изменится, значение в приложении и значение базы могут разойтись.

Оптимальным решением обычно является явный список целевых столбцов с пропуском полей, которыми управляет база. В результате приложение передаёт только свои данные, а база централизованно устанавливает статус; при этом вставка остаётся устойчивой к перестановке столбцов.

Что кандидаты часто упускают

Чем отличается пропуск столбца от явной передачи NULL?

Пропуск означает: «база сама выбери значение по умолчанию». Явный NULL означает: «запиши отсутствие значения», поэтому DEFAULT обычно не применяется. Это различие критично для полей статуса, дат и признаков, допускающих NULL.

Что произойдёт, если у столбца есть DEFAULT, но одновременно задано NOT NULL?

При пропуске столбца база применит DEFAULT, и вставка может пройти успешно, если результат не равен NULL. Если же клиент явно передаст NULL, сработает ограничение NOT NULL, поскольку значение по умолчанию не подменяет явно переданный NULL.

Почему список столбцов в INSERT важнее, чем просто удобство чтения?

Он фиксирует соответствие между выражениями источника и столбцами назначения. Без такого списка запрос зависит от порядка столбцов и может начать записывать данные не в те поля после изменения схемы или при переносе запроса между таблицами. Явный список снижает риск незаметной порчи данных и делает использование DEFAULT предсказуемым.