Scan: строки, NULL и указатели

Повторим механику из пятого урока с поправкой на NULL. Scan копирует колонки результата в приёмники строго по порядку SELECT и подбирает под каждый тип колонки план сканирования: для text-колонки в обычную string план тривиален — скопировать байты. Но у каждой колонки результата, кроме типа, есть ещё состояние: значение или NULL. Приёмники по этому признаку делятся на два лагеря. Nullable-aware — указатель на значение, pgtype.Text, sql.NullString — NULL принимают и превращают в своё представление пустоты. Не-nullable — plain string, int, float64 — NULL принять не могут и возвращают ошибку с внятным текстом: cannot scan NULL into *string — драйвер называет тип приёмника, который не справился. Важная деталь, на которой спотыкаются: ошибка вылетает не на Query, а в момент Scan конкретной строки. Сам SELECT выполнен успешно, сервер отдал данные, курсор открыт — а падает уже распаковка. В логах это выглядит так: запрос прошёл, а сервис упал позже, и связать одно с другим без понимания механики трудно. Проверяйте err именно после Scan, а не только после Query, — это правило уже звучало в пятом уроке, здесь у него появляется второе основание.

Под капотом pgx видит приёмник типа «указатель на указатель» — вы передали адрес переменной, в которой лежит *string, — и включает специальный план: для NULL он оставляет указатель nil, для значения аллоцирует строку и сканирует в неё. Это самый лаконичный путь: объявление поля и обработка пустоты не требуют никаких дополнительных типов. У nil есть и практические бонусы на границах приложения: json.Marshal превращает nil-указатель в null, а пустую строку — в пустые кавычки, поэтому API, который отдаёт клиенту null для отсутствующей биографии, получается почти бесплатно. Обратная сторона — nil-дисциплина по всему коду. Каждое использование требует проверки: bio != nil, иначе разыменование приносит панику; строковые методы вызываются только после проверки; в шаблонах и отчётах появляется ветка «поле есть — поля нет». Работает и обратная вставка: nil-указатель в аргументах INSERT уезжает на сервер ровно как NULL, а указатель на строку — как её значение, так что запись тоже обходится без преобразований. Если указатели вспоминаются с трудом — вернитесь к материалу про ссылки и разыменование в базовом курсе: без уверенной работы с nil в этом разделе делать нечего.

Второй путь — pgtype.Text: структура с двумя полями, String и Valid. NULL превращается в Valid: false и пустую String; обычное значение — в Valid: true и саму строку. Разыменований нет, паник нет, есть явная ветка if v.Valid — код с ней читается однозначно, даже если читатель ни разу не видел pgtype. Тот же паттерн реализует sql.NullString из database/sql: в нативном pgx он тоже работает, потому что реализует интерфейс sql.Scanner, который pgx уважает наравне со своими типами. Почему я почти всегда беру pgtype.Text, а не sql.NullString? Он родной для этого драйвера: единый стиль со всеми типами десятого урока — UUID, NUMERIC, timestamptz, — одна и та же конвенция Valid во всём слое данных, и никакого моста через интерфейс database/sql. Для sql.NullString у меня осталось одно применение: код, который живёт в двух мирах — pgx и *sql.DB из девятого урока. Внутри же нативного кода смешивать две библиотеки нулевых типов — лишняя когнитивная нагрузка без выгоды. Объявление с pgtype.Text чуть многословнее указателя, зато полностью избавляет слой данных от nil-проверок — и это, как правило, выигрывает у экономии на объявлении.

Часть NULL-проблем честнее решать до Go. COALESCE(bio, '') подставляет пустую строку вместо NULL прямо в выборке — приёмник остаётся обычной string, и nil-проверки в коде не нужны вовсе. Это оправдано, когда нулевость для бизнес-логики не значима: показать биографию или заглушку, посчитать отображаемое имя. Фильтрация — через IS NULL и IS NOT NULL: WHERE bio IS NULL вернёт ровно строки без значения. Ловушка, которую обязан знать каждый: сравнение bio = NULL никогда не истинно — даже для строк с NULL, потому что NULL в сравнении даёт не «да» и не «нет», а UNKNOWN, и строка просто не попадает в результат. Это не баг драйвера, а трёхзначная логика SQL, о которой стандарт договорился задолго до Go. Сортировка тоже помнит про NULL: по умолчанию при ORDER BY bio DESC нулевые значения оказываются первыми — лента с анонимными профилями наверху обычно не то, чего хочет продукт; лечится явно — ORDER BY bio DESC NULLS LAST. Граница между «решаем в SQL» и «решаем в Go» простая: если различие NULL и пустоты значимо для поведения — решаем в Go с приёмниками из этого урока; если значим только вывод — пусть SQL нормализует сам.

NULL меняет ответы не только при сканировании строк, но и внутри запросов — и это вторая половина темы. COUNT(*) считает строки, COUNT(bio) — только строки, где биография есть: таблица из пяти пользователей с двумя NULL покажет 5 и 3, и оба числа правильные, просто они отвечают на разные вопросы. AVG и SUM игнорируют NULL, поэтому средний возраст по неполным данным считается по заполненным строкам — возможно, то, что нужно, а возможно, и тихое искажение отчёта. Отдельная мина — SUM по пустому набору: он возвращает не ноль, а NULL, и после Scan в обычный int вы получите уже знакомую ошибку сканирования; стандартное лечение — COALESCE(SUM(views), 0). Самая коварная конструкция — NOT IN с подзапросом: если подзапрос вернул хоть один NULL, WHERE id NOT IN (...) не вернёт ничего, потому что сравнение с NULL даёт UNKNOWN для каждой строки. Разбирают такие баги редко и дорого — проще не выпускать: в запросах с NOT IN добавляйте WHERE ... IS NOT NULL во внутренний выбор или переходите на NOT EXISTS. Все перечисленные сюрпризы живут в SQL и воспроизводятся без всякого Go — их стоит один раз увидеть на тестовой таблице.