pgAdmin 4 и DROP FUNCTION

"Ничего не сделал, только зашел" (с) кино

К своему великому счастью год не обращался к теме Постгреса, но в связи с переустановкой серверов разработки недавно пришлось "взять в руки шашки". Сразу обнаружилось, что pgAdmin 4 не только переписали на г... пардон, на новых технологиях, но и перестали поддерживать версию 3.

pgAdmin 4 bug

Версия 4-1.5 (четыре полтора) производит впечатление поделия, не работающего сразу после установки. Посему возник естественный вопрос: "Что нынче рекомендует ЦК ВЦСПС для администрирования нашей главной хипстерской импортозамещательной СУБД?" Однозначного ответа в фейсбучной группе не нашлось, некоторые лишь подтвердили мой вынужденный выбор последней доступной версии "тройки".

"Оставайтесь с нами, мы будем следить за развитием ситуации" (с)

Не далее как вчера в программе установки обновлений потребовалось превентивно удалять хранимые процедуры (в Постгресе - функции). К сожалению, оператор DROP не работает просто так, необходимо указать полную сигнатуру в виде

DROP FUNCTION my_func(int, int);
DROP FUNCTION my_func(int, int, int);

и т.д.

Концепт, весьма спорный, тем не менее ясен: функции в Постгресе можно перегружать, поэтому чтобы удалить нужную, надо специфицировать. А если надо удалить все функции заданного имени?

Stackoverflow предлагает много способов из разряда "стоя в гамаке". Пришлось использовать запрос со внутренними функциями, формирующий оператор DROP вместе с сигнатурой.

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

Вроде бы очередная мелочь, но дающая неплохое представление о том, как "проектируются" решения в базаре. "Прикрутить фичу", а там хоть трава не расти. Недоволен - код открыт, сам допиши.

Для сравнения, SQL Server не предлагает перегрузки хранимых процедур, но позволяет их нумеровать. Следующие вызовы выполняют разные код.

EXEC my_proc;1;
EXEC my_proc;2;

При этом DROP my_proc ожидаемо удалит всю группу my_proc. Ну, подумали люди не только про "фичу", но и про последствия её использования. Есть у проектировщиков глобальное видение системы.

P.S. 2017-12-04 по наводке от Дмитрия Белявского, коллега которогопознал ад сортировки Юникода в Постгресе.

При сортировке в юникодной локали PostgreSQL выдаёт записи в следующем порядке:

_a
a
_c
d

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

Обходится проблема наложением на искомую колонку COLLATE "C", что даёт почти бинарное сравнение с учетом подчеркивания.