Одна таблица результатов на 14 движков: как мы перестали дорисовывать то, чего движок не умеет

[cevheri]

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

Первый: несовместимость проявляется не только на уровне протокола, но и внутри одного и того же каталога. Мы фильтруем системные схемы одним общим списком, и он оказался несущим, а не косметическим. Обзор считает pg_tables напрямую, а объектный браузер читает information_schema. На CockroachDB объекты crdb_internal попадают в pg_tables, но не проходят фильтр BASE TABLE в information_schema, поэтому две панели одного приложения показывали 98 и 2 таблицы для одной и той же схемы. На TimescaleDB браузер показывал 61 таблицу там, где пользовательских было 2: 34 чанка, 22 каталожных, 3 кеша. AlloyDB Omni: 10. Cloudberry: 4.

Второй ближе к проблеме Cassandra из статьи, но общее правило шире: сентинел легко превращается в измерение. PostgreSQL 14+ пишет в pg_class.reltuples значение -1, и это значит "я это не считал", а не "строк нет". Пока мы приводили его к нулю, таблица с тремя строками честно рапортовала, что пуста. Теперь -1 и NULL становятся отсутствием значения, и бейдж просто не рисуется, как в остальных случаях из статьи.

Честно про границы: правило "не ветвиться по типу движка" мы держим только внутри слоя провайдеров. В UI до сих пор живут три ветки по mongodb, и они у нас записаны как долг, а не как замысел.