Симонов ДенисЕсли организовать так как ты хочешь данная фича была бы бесполезной

потому что она не относится к безопасности, она относится к SELECT/VIEW и назыввать ее security - обман

Dimitry SibiryakovНет, нарушением security как раз будет выброс ошибки, подтверждающей, что запись
CLASS_ID=5 в природе существует.

ого!
ну тогда выброс ошибки нарушение PK unique constraint при insert с повторным ID - тоже нарушение безопасности, "подтверждающее, что запись ID=<<PK duplicate>> в природе существует."

sereginsereginПользователь запросил данные - ему предоставили все доступные. Какие еще существуют записи в БД - ему знать не положено.

пользователь вообще не должен запускать IBExpert, а должен работать с пользовательским приложением, которое и обеспечит формирование правильных запросов теми или иными способами (хоть через VIEW и SP, хоть как угодно)

если же пользователь может создавать свои запросы ,то как проверить наличие невидимых данных он найдет - хоть через select count(*), хоть через update ... where ...

sereginsereginМимопроходящийHello, Sereginseregin!
You wrote on 26 октября 2016 г. 16:39:06:

пропущено...
а смысл?






Как-то это стрёмно, делать временные метаданные

Правильнее казалось бы делать постоянные GTT с привязанной инструкцией по заполнению их нужными данными при первом обращении

CREATE GLOBAL TEMPORARY TABLE xxxx (......)
on commit delete rows
on first use ( insert into xxxxx select .... )

Симонов ДенисArioch,то как проверить наличие невидимых данных он найдет - хоть через select count(*), хоть через update ... where ...

да неужели. count(*) уже работает с неявным фильтром.

....если про это не забыли

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

а если не забудут - вот и получили случай, когда row-level invisibility резщко замедляет работу

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

в топку.

да GTT вообще в топку

ни разу их не использовал - значит никому они и не нужны

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

вкусовщина

Симонов ДенисИ кстати пару раз эта штука вынесла мне мозг, пока я не догадался, что у них на таблице политика стоит

просто прекрасный aргумент в пользу реализаций выборки данных через abuse системы безопасности

про аналогичную проверку через update ты, к слову, промолчал

равно ты скоре всего не проводил сравнение на Оракле select count(*) c индексированной большой таблицей с политикой частичной невидимости по неиндексированному полю и без политик вообще

сравнение по скорости

AriochКак-то это стрёмно, делать временные метаданные

Правильнее казалось бы делать постоянные GTT с привязанной инструкцией по заполнению их нужными данными при первом обращении

Симонов Денисвот твоё решение не очень

ну например вот тут бы она могла пригодиться - http://www.sql.ru/forum/1236092/

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

во всяком случай на мой взгляд это лучше, чем делать временный изменения метаданных

Хотя.....

Вы же в FB3 ввели разные неймспейсы, так ? Или я путаю ?

Почему бы не ввести неймспейсы connection-local и transaction-local ? тогда вышеупомянутая фишка Постгресса будет повторена без создания специфических расширений SQL-комманд.

Как для SET$CONTEXT есть области видимости "текущее соединение" кажется?
и аналогично сделать с неймспейсами.

create view CURRENT_CONNECTION.TEMPORARY_SELECT AS .....

при дисконнекте - само умирает вместе с неймспейсом

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

тут дело опыта. Я тогда с ораклом мало знаком был. Теперь то в случае чего смотрю, а не висит ли на таблице политика.

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