Начиная с 9.7.4 в шаблоне like можно использовать выражения с полями типа:

Между прочим, ещё один пример фичи неоднозначной полезности. Казалось бы, замечательно - появилась новая возможность. Но я сильно подозреваю, что теперь ей начнут пользоваться, когда можно и лучше было бы без неё обойтись. Запрет на выражение в LIKE имел смысл для принуждения, чтобы люди пользовались только константами, а оптимизатор мог эти константы разобрать и построить более оптимальный план. А что оптимизатор сможет сделать с шаблоном, который до выполнения SQL-выражения ему неизвестен?

В Oracle уже давным давно можно в like использовать hostvar в качестве шаблона. В результате мне так и не удалось уговорить разработчика одной используемой нами системы при задании произвольного фильтра по выборке подставлять туда константу (это при том, что тот запрос и так динамически генерируется), но на пользу это никак не могло пойти (ни скорости выполнения запросов, ни разработчику, да и нам тоже).

Когда запрос формируется динамически, да ещё при применении GUI-фильтра (что наверняка означает, что сервер не бомбардируют тысячи подобных запросов в секунду), что мешает подставлять константу в LIKE?

Но ведь если не динамически, так это ещё хуже. Я предпочитаю давать серверу максимум информации для оптимизации. Конечно, при этом на сервер ложится лишняя работа по разбору и прекомпиляции, но если запросы идут не очень часто, то беспокоиться не о чем, а на средних и больших объёмах данных это окупается.

(Поскольку я не знаю вашей ситуации, то мысленно подставляю свою. Где имеются десятки миллионов документов (авиабилеты) и десятки полей с разнообразными (попросту произвольными) условиями фильтрации по любым полям. У вас, наверное, много меньше того и другого, и потому вам действительно наплевать. Но я бы всё равно побеспокоился).

Troglodit1. у пользователя должны быть права на все таблицы (или view) используемые в запросе.
И в чём проблема?
2. при изменении запроса нужно лезть в код приложения (это не есть хорошо).
Куда-то ведь всё равно придётся лезть?
3. если запрос использует временные таблицы (т.е. превращается в простыню), то п.2 превращается в ад.
Какие такие "временные таблицы"? И если это то, о чём я подумал - ну, используйте VIEW, если вас большой запрос смущает.
4. Время на подготовку запроса может быть сравнимо с временем выполения (имхо).
Вот если будет, тогда другое дело.
Ну и опять же опыт людей в данном форуме подсказывает, что при развитии проекта поддерживать процедуры/функции легче, чем внутри приложений.
Чем легче-то? Так и так база и приложения должны быть согласованы друг с другом, код должен храниться в системе управления версиями, приложение должно отказываться работать, если его версия не соответствует базе.

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

View и SQL-функции есть (я их за view с параметрами считаю).
Я может неправильно выразился. Конечно код придется менять,но в SQL процедуре, при этом для клиента это все будет прозрачно,плюс человек(если проект пишет больше одного), который пишет прикладную часть, не загоняется,а пользуется готовой процедурой.

Не знаю насчёт "загоняется". Но ведь нельзя сделать select .. from процедура. Это значит, что надо будет делать процедуры на каждый чих? И/или делать запросы в них чудовищно неэффективными, a la
Фу. А потом нам говорят, что у нас слишком слабый сервер для их крутой суперсистемы.
Если приложений несколько (веб,десктоп,мобильный), то зоопарк с различными ЯП проще устранить, когда вся бизнес-логика находится в БД.

Абстрактно не могу не согласиться, конкретно надо смотреть. Учитывая существование view и sql-функций.

Чем легче-то? Так и так база и приложения должны быть согласованы друг с другом, код должен храниться в системе управления версиями, приложение должно отказываться работать, если его версия не соответствует базе.
Это в идеале, по факту такое далеко не всегда.

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

Клиенту нельзя давать доступ на таблицу, поскольку это коммерческая инф. других юр.лиц.
Вагоны имеют свойства продаваться другим юр.лицам,но история должна показываться текущему клиенту.
У клиента может быть несколько юр. лиц и он хочет единый интерфейс.

Вот что можно было делать ещё в DB2 2.1 for OS/2, да наверняка и до этого на мейнфреймах тоже:

some_sensivite_table - таблица, часть которой мы показываем текущему юзеру, а часть не показываем.
Данные разбиты на секции.

some_sensivite_table_rights - там пары - (user, section)

Юзера не имеют права на указанные таблицы, а только на указанный view.

Дальнейшее, полагаю, понятно, и что идею можно развивать - тоже.