Не заебись: оператор in они хуёво нормализуют, приходится за них статистику доагрегировать.

@enterprize Не-не-не, это, скорее всего, программисты у тебя криворукие пидорасы и не умеют правильно передавать аргументы в запросы с IN. Тебе ведь там $1, $2, $3, $666 сыпет?

@komar Не угадал: in (?, ?), in (?, ?, ?, ?, ?) и ещё миллион вариантов на эту тему.

@enterprize Ну я эту хуйню в логах ловил, а не в этом экстеншоне, поэтому у меня доллары были вместо вопросов. Короче, зырь как надо: WHERE id = ANY($1::bigint[]) А аргумент вот так кодировать: {hui,"piz da",NULL,2}

@enterprize А, не, наебал, ? тоже за них скрипт делает. Да, там $666.

@komar (ну то есть в данном случае только циферки в качестве аргумента годятся, я просто для примера привел)

@komar Заебись, спасибо, пойду выпучу этим глаза погромистам на крестах.

@enterprize Собственно, это единственный способ сделать prepared statement с IN’ом переменного размера. Справедливости ради, приготавливать его смысла никакого. Но если б они хотя бы попытались, то узнали бы про этот уродливый и неочевидный способ.

@komar Приготавливать они уже пытались, кстати. У них там преждевременные оптимизаторы какие-то были, которым я даже preprepare за pgbouncer по приколу завёл, чтобы наглядно показать, что им это не поможет.