Комментарии 11
Радует, что potgresql становится всё больше совместим как со стандартом (MERGE), так и с другими СУБД (например, в версии 14 добавили out параметры в процедурах).
Начали плотно заниматься переездом с MSSQL на Pg и сходу столкнулись с нереализованной фичей в Pg.
У нас аналитики привыкли писать простыни кода вида:
set @var_1 = null
set @var_2 = null
select top 1 @var_1 = field_1, @var_2 = isnull(field_2, 0) from table_1 with(nolock) where field_3 = 'X'
and feld_4 = @param_1
if @var_1 is null
begin
...
end
else if exists(select * from sys.procedures where name = 'proc_1')
begin
exec dbo.proc_1 'arg_1', @var_2
end
...
select @var_1, @var_2, ...
Т.е. в коде выполняется блок бизнес логики с вызовом процедур, селектом из таблиц, управляющими конструкциями и финальной выборкой из блока. И к сожалению это не переписать на функции БД по ряду причин.
Наиболее близкое, что нашли в PG - это блок DO, но относительно MS SQL он имеет несколько отсутствующих возможностей:
Нельзя передавать в блок DO параметры.
Нельзя в блоке DO делать выдачу результата. Только через курсоры или временные таблицы
Собственно вопрос в наличии планов по развитию анонимных блоков в PG как в базовой версии, так и в версиях Postgres Pro?
Про такие планы ничего не слышно. Параметры и возвращаемый результат - это все-таки про функции и процедуры. Не очень понятны причины, почему их не использовать.
Организационные ограничения. Такие блоки кода лежат в файлах конфигурациях некоторых сервисов. Эти конфигурации документируются, версионируются, складываются в gitlab, раздаются клиентам.
Возможно сами сервисы могли бы по файлам конфигурациям создавать функции в БД, но полагаю, что это приведет к неконтролируемым проблемам, например, замусориванию, так как при удалении чего-то из файловой конфигурации не будет удаляться из БД, опять же изменения не отследить, нужно будет каждый раз при старте функции пересоздавать.
В данном примере вполне можно выдать эти переменные из DO блока через RAISE NOTICE.
Так же, в ряде случаев, "переменные" можно организовать через
WITH vars AS (SELECT 1 AS var1, 'blablabla' AS var2, '2022-10-22'::date AS var3)
Спасибо, но это был лишт один из примеров. В куче мест финальная выборка табличная. Про WITH знаю, но там внутри код на plpgsql не выполнить же.
Ну тогда через таблицу. Временную или постоянную. Благо в PostgreSQL массив записей можно в одном поле возвращать.
Или воспользоваться сериализацией в JSON, в который можно засунуть даже несколько табличных выборок и вывести через RAISE NOTICE.
Через RAISE NOTICE можно и массив записей выдать, но для них нужен тип да и вывод текстовый, что не всегда удобно.
Вот что не хватает в этом обзоре, так это брифа прошедших конференций по PostgreSQL в Австрии и Германии. Там было интересное.
Технический директор — Алексей Палажченко, организатор Golang Moscow.
Ссылка, однако, ведёт на не связанную с Golang Moscow конференцию Golang Conf.
Golang Moscow был тут: https://www.meetup.com/ru-RU/Golang-Moscow/
Наша конференция GopherCon Russia была тут: https://www.gophercon-russia.ru
На Golang Conf я только выступал один раз.
Postgresso 8-9 (45-46)