rdb_dev,

если я не ошибаюсь в стандарте нет вообще привилегий, которые могут быть выданы процедуре, триггеру или любому другому объекту БД кроме пользователей и ролей. По крайней мере ни в одной другой СУБД я такого не видел. Там максимум можно указать с какими правами выполняется процедура (вызывающего пользователя или определяющего, см. предложение SQL SECURITY {INVOKER | DEFINER} (будет в 4.0)). Так что FB здесь скорее всего весьма расширил стандарт.

MaratIsk,

где кроме IB/FB и их клонов?

Напомню речь о выдаче привилегий процедуре на другие объекты метаданных




а не привилегий на выполнение процедуры

rdb_dev,

я помню. Ты упомянул стандарт, поэтому я продолжил речь о стандарте. Поскольку стандарта у меня на руках нет, я не могу с уверенностью утверждать, что там говорится на этот счёт. Но попытался поискать, что сделано в других популярных СУБД, и обнаружил, что там вообще никаких прав процедуре не выдаётся. Права процедур там регулируются с помощью предложения SQL SECURITY. У нас такая фича тоже уже есть в 4.0 в дополнение к привилегиям процедуры, что существенно облегчит администрирование.

ИХМО предлагаемое расширение оператора REVOKE было бы полезно. Особенно если кто-то решит поменять процедуры на SQL SECURITY DEFINER в 4.0, чтобы лишние привилегии не болтались. Если есть желание сделай тикет в трекере.

rdb_dev,

то что гибкость больше никто не спорит. А вот удобство совсем другой вопрос. Чаще всего процедуре дают права на все объекты которые в ней используются. В этом случае гораздо проще просто написать процедуру с предложением SQL SECURITY DEFINER и не думать над правами каждый раз когда изменяешь процедуру. Хотя могут быть и другие варианты.

В этом плане 4.0 в сочетании с ролями по умолчанию (ака группы) позволяют настраивать привилегии очень гибко.

rdb_dev,

ясен пень. С высокой долей вероятности как только выйдет релиз 4.0, FB 2.5 вообще снимут с поддержки.

Политика примерно такая.

2.5 (предыдущая) - только исправление ошибок.
3.0 (текущая) - исправление ошибок и улучшения.
4.0 (в разработке) - новые фичи, исправления ошибок и улучшения.

Исключения могут быть, но они весьма редки.

REVOKE ALL ON ALL FROM {TRIGGER | PROCEDURE | ...} ...

это скорее улучшение, а не новая фича. В любом случае если у тебя есть потребность сделай тикет в трекере, там решат делать ли это, и портировать ли в предыдущие версии (если будут делать конечно).

MaratIsk,

я с этим не спорил. Почитай топик целиком.
Я только сказал, что не знаю ни одной СУБД, в которой права на объекты метаданных даются процедуре, триггеру, функции или пакету. На выполнение или вызов процедуры (EXECUTE) есть практически везде.

Симонов Денис,

кроме IB/FB

MaratIsk,

ну и как? Нет такого оператора в SQL Firebird. rdb_dev помимо основного вопроса хотел спросить с чем это связано, а так же узнать что говорится в стандарте по этому поводу. Я сказал, что предполагаю что в стандарте вообще про это ничего не написано.

MaratIskвпрочем, добавил бы - тема - яйца выеденного не стоит

ну почему же? Я считаю что такой оператор был бы полезен. А вот шанс его введения особенно в 2.5 не велик.