столкнулся с тем, что запрос с конструкцией

ГДЕ Наименование ПОДОБНО "%блабла " + &Шаблон + "%"

под MS SQL работает нормально, а при переносе под Postgre - НЕТ, результат вместо ожидаемого пустой
&Шаблон - текстовая строка, "[АA]" (рус + лат)

хотя и там и там нормально отрабатывает конструкция

ГДЕ Наименование ПОДОБНО "%блабла [АA]%"

фича? баг? с чем это может быть связано?

не спасает даже
(ВЫРАЗИТЬ("%блабла " КАК СТРОКА(8))) + (ВЫРАЗИТЬ(&Шаблон КАК СТРОКА(4))) +  (ВЫРАЗИТЬ("%" КАК СТРОКА(1))))

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

https://its.1c.ru/db/v8std/content/726/hdoc

(0) уж сколько лет )

и они еще борются за почетное звание дома высокой культуры быта
фабричным респект, по сути три строковых константы сложить - этож высшая арифметика

(5) ну так и сложи перед помещением в параметр запроса, оспаде.

(0) на постгри много чего не так, как на скуле

(6) тут понимаешь в чем дело, я со скулем с 95-го года
когда 12 лет назад с 7.7 переползал на 8.2 радовался - я язык запросов почти весь знаю
ну подучить всякие там параметры оборотных/остаточных регистров пришлось
и я в полной уверенности, что я крут и язык запросов весь знаю...

ан нет - обломись!

причем этим "трюком" пользовался уже и не помню сколько лет, а тут раз - ЗАПРЕЩЕНО!

картина мира сломалась

(8) столько лет опыта а так и не догнал, что всё что можно сделать на клиенте с параметрами запроса - на клиенте и требуется делать... гнать таких из профессии ссаными тряпками!

(9) да я... а ты...

(9) но баг остается багом

(11) >> баг остается багом.

Это не баг. А особенность.
О которой 1С честно предупреждает разработчиков в (3) с пояснениями.
Думаю, если бы проблема легко решалась, то за столько лет уж как-нибудь пофиксили бы её. Либо решение слишком нетривиальное, либо применить его ко всем СУБД невозможно.

(11) документированный баг = фича

картонкой опуприкрыли, а не задокументировали

(14) в трассировке глянь запрос к бд