На самом деле, если редакция сервера не позволяет, или лень разбираться с безопасностью на уровне строк - можно проще, и более кондовым способом.
Нужно создать View, в котором фильтровать записи, в зависимости от пользователя, соответственно встроив логику security function в запрос, лежащий в основе View.
Ну и, соответственно, закрыв везде доступ для пользователей к таблицам, и открыв - к вьюхам.

Кстати, у такого подхода есть несколько значительных преимуществ перед вариантом с row level security.
1. Производительность.
Когда вы определяете security function для какой-то таблицы она всегда применяется через nested loop к каждой строке таблицы. И если этих строк МНОГО - это влетит вам в копеечку с т.з. производительности.
Если вы определили security function с использованием каких-либо пользовательских таблиц (например - списка принадлежности пользователя к филиалу) - нужно позаботиться, чтобы эта вспомогательная таблица была правильно проиндексирована, а запрос, лежащий в основе security function - был очень, очень, очень оптимизированным.
Имейте также ввиду, что вы, скорее всего, лишитесь возможности использовать подсказки уровня запроса, типа option (hash join), поэтому ваш прикладной код может внезапно сломаться, если вы навесите секьюрность потом, на работающий код.
2. Отсутствие возможности "запретить" row level security для каких-то отдельных запросов, и оставить включенной для всех остальных.
Вам также придется не забыть прописать в security function явным образом возможность для суперпользователей просматривать всё содержимое.

Короче говоря, row level security - хороша всем, если вы навешиваете ее на небольшую табличку, максимум в пару десятков миллионов записей, ваша security function представляет из себя скалярное выражение, и вам никогда не потребуется прочитывать всю таблицу из под ограниченного пользователя. Ну и программисты у вас не криворукие рукожопы.

Я, например, вынужден был отказаться, и вернуться в вьюхам.