nekocave.xyz
#Google #Gemini тоже ебанулся.
Промпт
------------------------
postgresql 17.
[часть, где создается таблица tablenames, пропущена]
Напиши SQL, который выведет мне две таблицы.
В первой таблице:
SQL запросы, чтобы удалить все индексы с таблиц из списка tablename. Примарные индексы, identity columns, FK — трогать запрещено строго настрого;
Во второй таблице: SQL-команды на восстановление их всех обратно.
Обрати внимание, часть моих таблиц - партициированы. У меня нет никаких уникальных индексов ТОЛЬКО партициях. А все индексы на родительской таблице передаются и на партиции автоматически.
Без string_agg пожалуйста.
Ответ коротко. Дай только код.
------------------------
Это говно создало код, который СПЕЦИАЛЬНО не дропает уникальные индексы.
-- Queries to drop indexes
SELECT 'DROP INDEX CONCURRENTLY "' || n.nspname || '"."' || c.relname || '";' AS drop_statements
FROM pg_index i
JOIN pg_class c ON c.oid = i.indexrelid
JOIN pg_namespace n ON n.oid = c.relnamespace
JOIN pg_class t ON t.oid = i.indrelid
JOIN pg_namespace tn ON tn.oid = t.relnamespace
JOIN tablenames tl ON tl.tablename = t.relname AND tn.nspname = n.nspname
WHERE i.indisprimary = 'f'
AND i.indisunique = 'f'
AND NOT EXISTS (
SELECT 1
FROM pg_constraint con
WHERE con.conindid = i.indexrelid
AND con.contype = 'f'
);
Засунул тот же самый код и промпт в #Grok 4.
Его ответ:
-------------
В методе Read отсутствует reader.Read() после получения имени свойства (перед JsonSerializer.Deserialize), что оставляет reader на PropertyName вместо значения. Кроме того, лишний reader.Read() после Deserialize и в case EndObject приводит к перечитыванию или пропуску токенов, особенно в массивах.
-------------
ТОЧНЕЙШАЯ БАЗА С ПЕРВОГО РАЗА. Какого хуя блядь?
Also, я думал, что буду ругаться и на грок, а оказалось, что у меня почему-то поменялась моделька с Grok 4 на говно. При этом в хинтинге поля ввода онв называлась "Эксперт", как и Grok 4.
#ХтоническаяНенависть #GoogleGemini #Grok #gpt #искусственныйидиот
Ну это просто #пц, ну я не верю, что такие совпадения бывают.
На всяк случай, я перепроверил модель: #Gemini 2.5 Pro
У меня есть самописный CacheConverter<T>, расширение класса JsonConverter<T>.
Там кидается ошибка "read too much or not enough".
Это хуепутало сказало удалить reader.Read() после "JsonSerializer.Deserialize(ref reader...".
Я у него спрашиваю, мол, "точно в case JsonTokenType.PropertyName:", а не в "case JsonTokenType.EndObject". Это хотя бы логично.
Этот выблядок говорит:
-------------------------
Да, я абсолютно уверен. Проблема именно в блоке PropertyName, а не в EndObject.
Код в блоке EndObject полностью корректен и необходим.
case JsonTokenType.EndObject:
{
reader.Read(); // Эта строка правильно потребляет токен '}'
needBreak = true;
break;
}
-------------------------
Я поправил: Код стал кидать ошибку про неправильный объект во время обхода токенов (потому что курсор установлен на VALUE в Dictionary).
Он говорит, теперь вставьте reader.Read перед JsonSerializer.Deserialize — всё равно такая же беда.
Та же ошибка про неверный объект в обходе.
Он говорит "оставьте оба reader.Read", опять вернулись к "read too much or not enough".
Далее этот хуесос мне говорит:
-------------------------
Понимаю, что ситуация становится запутанной. Давайте прекратим "передвигать" строку Read() и посмотрим на проблему под другим углом.
Корень зла — это конфликт управления. У вас есть цикл while(true), который пытается вручную управлять чтением JSON, и есть высокоуровневый метод JsonSerializer.Deserialize(), который тоже пытается управлять чтением. Они "дерутся" за ридер, и из-за этого возникает рассинхронизация.
-------------------------
И выдаёт мне код с ровно таким же behaviour, как у меня, просто написан другим способом.
Короче, я убрал reader.Read из case JsonTokenType.EndObject и получил:
================================================
Чуваки, я не хочу теории заговора разводить, но я не верю, что два сдохших ИИ в один день это совпадение.
А в итоге оттуда и надо было удалить