Права доступа вполне себе доступно и понятно описаны в документации. Глобальные привилегии ролей, пользователей - по команде CREATE ROLE: https://postgrespro.ru/docs/postgresql/11/sql-createrole из этой доки ведут ссылки на описание ролевой модели ПГ и способов аутентификации.
Права доступа к объектам - по команде GRANT: https://postgrespro.ru/docs/postgresql/11/sql-grant
Необходимо помнить, что командой GRANT вы выдаёте права только для УЖЕ СУЩЕСТВУЮЩИХ объектов! Для назначения прав по-умолчанию, используется команда ALTER DEFAULT PRIVILEGES: https://postgrespro.ru/docs/postgresql/11/sql-alterdefaultprivileges
По транзакциям: https://postgrespro.ru/docs/postgresql/12/mvcc лучше прочитать всю главу, я думаю.

В качестве домашнего задания найдите в документации информацию по pg_hba.conf

А жаль, что примеров так мало (и нет примеров типичных схем раздачи прав), IMHO.
Потому что если пытаться этим заниматься всерьёз, а не просто "да мы всё в приложении спрячем и проконтролируем", можно неожиданно (а если нужно RLS — вообще запросто, мне кажется) "влететь", и это из документации не очевидно (и информация, к тому же, разбросана по разным разделам).

В общем, Вы видели где-то хорошее описание принципов схем раздачи прав на примерах?

на примерах — нет. всё основано на опыте, как в Oracle, так и в Postgres. справедливости ради, хороших систем доступа встречал мало, и они в целом были похожи между собой (как я описал выше). с RLS проявляются косяки в планировании запросов, но пока получалось обходить незначительными изменениями самих запросов

Жаль.

> и они в целом были похожи между собой

Мне кажется, что если при этом подходе "ляпнуть" в какой-то мелочи, можно запросто открыть (и даже для изменений) то, что совсем не планировалось.

> с RLS проявляются косяки в планировании запросов

Да я же не об этом. У меня ощущение, что на самом деле многие из т.н. RLS (особенно, если они не основаны на встроенных механизмах) — это "решето". ;)
Т.е. тот, кому это нужно и кто в этом разбирается, "вытащит" кучу той информации, которая ему совсем не предназначалась. :(

Почему нет типичных примеров - потому что пока не вот уж есть инсталляций в достаточном количестве, где права доступа разруливаются на уровне СУБД. Обычно на уровне приложения, а в БД ходит приклад под одной учётной записью. И второе - в каждой избушке свои погремушки. Надеюсь, этот факт не надо разъяснять.
Ну и я считаю, как выше написал, что в документации достаточно информации, чтобы грамотно рулить правами доступа. Другое дело, что к этому рулению надо подходить аккуратно и вдумчиво, особенно при использовании функций для доступа к данным. И процедура эта - отнюдь не пятиминутная.

ЗЫю Для ускорения процесса раздачи прав вполне себе полезно будет вспомнить, что основные орудия проектирования после собственно мозгов - это ручка и бумажка. :)

>  пока не вот уж есть ... где права доступа разруливаются на уровне СУБД
> Обычно на уровне приложения, а в БД ходит приклад под одной учётной записью.

Что значит, что в этих случаях документация, фактически, не имеет отношения к делу, и это вариант "да мы всё в приложении спрячем и проконтролируем", нет? Или же, если это типичная схема, было бы неплохо, если бы принцип раздачи прав под неё был описан (с примерами и особенно её ограничениями / "врождёнными дефектами"), мне кажется.

> в документации достаточно информации, чтобы грамотно рулить правами доступа.

Формально-то да... Но (в качестве аналогии) и в стандарте SQL, например, "достаточно информации" для реализации conforming SQL implementation, но что-то все fail-ят (причём, по-разному) во многих случаях (включая PostgreSQL), хотя и стараются. ;)

> Другое дело, что к этому рулению надо подходить аккуратно и вдумчиво

Ну и было бы неплохо, если бы "типичные" подходы, решения и ошибки были описаны, чтобы не было, как с ISO SQL.
А так описываются почти исключительно инструменты, а не то, как ими работать и что делать, я вот о чём.
И я не имею в виду, что это должно быть в документации — книга, wiki или статья тут даже больше подходят.

Допустим, но зачем все должны ходить по тем же граблям (особенно, в "важном" production)? ;)

Уже можно говорить что JSON неюзабельный на больших объемах, так как канал забивает. Из-за чего приходится хранить как inflate bytea? ))

> У меня ощущение, что на самом деле многие из т.н. RLS (особенно, если они не основаны на встроенных механизмах) — это "решето". 😉

вот это не понял.
я под RLS подразумеваю только то, что база в этой области предоставляет.

реализации по типу “у нас за всё приложение отвечает” встречал неоднократно, там всё печально с целостностью… исключений не было.

> вот это не понял.

Я имел в виду в основном "самопальные" RLS, вместо того, что предоставляет PostgreSQL, т.е. "реализации по типу “у нас за всё приложение отвечает”", да.

Но и даже на основе "настоящего" RLS не так уж сложно "накосить", как мне кажется.

в крупных конторах вообще запрещают ролевую модель на БД реализовывать. безопасники на уровень приклада отправляют

ASN.1 и вперёд

??

странные “безопасники”… то, что я описывал, в одном из проектов (сеть компаний по всей Европе и ЛА) было согласовано и утверждено отделом безопасности в первую очередь.

На больших объемах удобно передавать данные кодированные по стандартам основанным на ASN.1

Т.е. это вариант — "молимся" на "приклад", и вся "безопасность"? ;)

просто те ограничения которые в итоге были реализованы (RLS в оракле) убили всю производительность

Во-первых, при чём тут PostgreSQL?
Во-вторых, это всё равно "молимся на приклад". Т.е. до первой "дыры" в нём работает, если кто-то её ждёт с нетерпением. ;)