Ну т.е. нужно написать уточнение, что нельзя в анонимном блоке

сделать как в ms sql, а в принципе есть вариант?

и в анонимном блоке можно

Но у тебя нет declare на скрине

мне тебе все варианты писать? ты можешь сам в гугле найти. это не какое-то тайное знание. просто анонимный блок - это аналог процедуры, он не создается и не имеет имени. а так это код на процедурном языке расширении. и там можно declare писать

Вариант аналога от Юрия Шапоренко напиши

Если мне не изменяет память, это DBeaver'овская имплементация psql-ного \set (в нем обращение к переменным также идет не через current_setting, а через двоеточие и название переменной)

DO $$DECLARE p_param int := 4; BEGIN perform 'select * from cron.job j where jobid = p_param'; END$$; только ты не понял, результат-то куда ты собрался выводить. это уже pg plsql

Ну да, вывести в той же DbForge набор строк не получится, как я понимаю?

нет, это же анонимной блок, а не запрос.

Iurii Shaporenko

Спасибо, это и имел в виду, когда заметку писал

Да не за что. Только учтите, что такие приколы с переменными, объявленными не через DECLARE в анонимном блоке/процедуре/функции, а через локальные/сессионные параметры, дают оверхэд по производительности, так как функция current_setting не иммутабельна, и для каждой строки значение переменной будет заново извлекаться

Ну получается, не стоит что-то в заметке менять, т.к. с точки зрения человека, кот-й писал скрипты с параметрами на t-sql все верно, это люди, работающие только с pg, могут в недоумении быть

Не совсем. Возможность использовать переменные в постгресе есть, и где-то они могут быть вполне уместны даже. Но можно и головняк на ровном месте поймать Например, по индексированному полю разница минимальна или ее нет вообще С переменной Limit (cost=0.56..11.16 rows=10 width=494) (actual time=0.072..0.082 rows=10 loops=1) -> Index Scan using sap_analisis_debet_customerreference_idx on analisis_debet (cost=0.56..356.73 rows=336 width=494) (actual time=0.070..0.078 rows=10 loops=1) Index Cond: (("CUSTOMERREFERENCE")::text = current_setting('my_vars.doc_id'::text)) Planning time: 0.462 ms Execution time: 0.159 ms Со значением Limit (cost=0.55..11.15 rows=10 width=494) (actual time=0.067..0.077 rows=10 loops=1) -> Index Scan using sap_analisis_debet_customerreference_idx on analisis_debet (cost=0.55..356.73 rows=336 width=494) (actual time=0.066..0.073 rows=10 loops=1) Index Cond: (("CUSTOMERREFERENCE")::text = '202106300ZBDR0ZRSF0Z02010000014325'::text) Planning time: 0.494 ms Execution time: 0.145 ms

тут уже оптимизатор работает. а он по-разному может строить планы для константы и переменной и понятно почему

Я работаю с оракелом в проде, просто жирные селекты пишутся очень-очень редко, обычно оно из приложения вызывается. В PG, наверное, так же?

оракл ведет себя очень похоже на postgres

Ну да, я плюс-минус это и имел в виду. То есть вот такие переменные в ПГ — это не просто инлайн какого-то значения в код, а обращение к функции, получающей значение сессионного параметра. А там уже зависит и от необходимости каста переменной к нужному типу и самого этого типа, и от наличия индекса по полю фильтрации, и от кардинальности значений, и еще куча вещей, которые аффектят на оптимизатор

Если запросы вызываются из приложения, то параметры логичнее разруливать именно на уровне приложения. С поправкой на защиту от инъекций и всякого такого, разумеется

не знаю как у кого, но у меня выражение "передавать параметры запросу" совершенно однозначно обозначает bind-параметры.

ты с ms sql не работал, видимо. можно прям скрипты фигачить с переменными и в оконцовке селект