Как сделать пользователя владельцем базы postgresql

Обновлено: 07.07.2024

Не безопасно, даем внешний доступ для IP 192.168.1.1 (можно использовать маски сети) Для подключения извне, также необходимо включить прослушивания внешнего IP
в настройках /etc/postgresql/X.Y/main/postgresql.conf

nano /etc/postgresql/X.Y/main/pg_hba.conf

Последующие записи не переобозначают предыдущие.
Предыдущие однотипные записи должны быть закомментированы
Это однотипные записи

методы аутентификации

trust
Разрешает безусловное подключение. Этот метод позволяет тому, кто может подключиться к серверу с базой данных Postgres Pro, войти под любым желаемым пользователем Postgres Pro без введения пароля и без какой-либо другой аутентификации.
ident
Получает имя пользователя операционной системы клиента, связываясь с сервером Ident, и проверяет, соответствует ли оно имени пользователя базы данных. Аутентификация ident может использоваться только для подключений по TCP/IP. Для локальных подключений применяется аутентификация peer
peer
Получает имя пользователя операционной системы клиента из операционной системы и проверяет, соответствует ли оно имени пользователя запрашиваемой базы данных. Доступно только для локальных подключений.
md5
scram-sha-256
Проверяет пароль пользователя, производя аутентификацию SCRAM-SHA-256 или MD5.

В PostgreSQL для работы с объектами роль должна иметь привилегии к этим объектам (таблицам, функциям). В этой статье разберёмся с привилегиями PostgreSQL.

Привилегий для разных объектов

Каждый вид объектов имеет разный набор привилегий, таблицы например имеют самый большой набор:

• SELECT – чтение данных;
• INSERT – вставка данных;
• UPDATE – изменение строк;
• REFERENCES – внешний ключ (право ссылаться на таблицу);
• DELETE – удаление строк;
• TRUNCATE – очистка таблицы;
• TRIGGER – создание триггеров.

Представления имеют всего две привилегии:

• SELECT – право читать представление;
• TRIGGER – право создавать триггеры.

• SELECT – право читать последовательность;
• UPDATE – право изменять последовательность;
• USAGE – право использовать последовательность.

• CREATE – разрешает создавать объекты внутри табличного пространства.

Базы данных имеют три привилегии:

• CREATE – разрешает создавать схемы внутри базы данных;
• CONNECT – даёт возможность подключаться к базе данных;
• TEMPORARY – разрешает создавать в базе данных временные таблицы.

У схем есть две привилегии:

• CREATE – разрешает создавать объекты внутри конкретной схемы;
• USAGE – позволяет использовать объекты в конкретной схеме.

У функций есть только одна привилегия:

• EXECUTE – даёт право выполнять функцию.

Категории ролей

С точки зрения управления доступом роли можно разбить на несколько групп:

• Суперпользователи – полный доступ ко всем объектам – проверки не выполняются;
• Владельцы – владельцем становиться тот, кто создал объект. Но право владения можно передать. Владелец имеет все привилегии на принадлежащий ему объект;
• Остальные роли – доступ только в рамках выданных привилегий на определённый объект. Такие привилегии могут выдать владельцы на свои объекты. Или может выдать суперпользователь на любой другой объект.

Выдача и отзыв привилегий

Выдать привилегию можно с помощью команды GRANT:

Забрать привилегию можно с помощью команды REVOKE:

Выданной привилегией можно пользоваться, но нельзя передавать другим ролям. Но владелец или суперпользователь может вместе с привилегией выдать дополнительную опцию, которая разрешит передавать привилегию другим ролям. Выдача привилегии с правом её передачи выполняется с помощью WITH GRAND OPTION:

Если мы дали привилегию вместе с правом её передачи. А затем роль воспользовалась своим правом и передала привилегию другим ролям. То забрать эту привилегию можно только каскадно у этой роли и у других ролей с помощью CASCADE:

Можно не отбирать привилегию, а только отобрать право её передачи. Это делается следующим способом:

Групповые привилегии

Роль получает привилегии своих групповых ролей. Нужно ли ей будет для получения привилегий выполнять SET ROLE зависит от атрибута роли, который мы можем указать при создании роли, как было показано на предыдущем уроке:

• INHERIT – атрибут роли, который включает автоматическое наследование привилегий;
• NOINHERIT – атрибут роли, который требует явное выполнение SET ROLE.

В 13 PostgreSQL при инициализации кластера создаются следующие роли вместе с суперпользователем postgres:

• pg_signal_backend – право посылать сигналы обслуживающим процессам, например можно вызвать функцию pg_reload_conf() или завершить процесс с помощью функции pg_terminate_backend();
• pg_read_all_settings – право читать все конфигурационные параметры, даже те, что обычно видны только суперпользователям;
• pg_read_all_stats – право читать все представления pg_stat_* и использовать различные расширения, связанные со статистикой, даже те, что обычно видны только суперпользователям;
• pg_stat_scan_tables – право выполнять функции мониторинга, которые могут устанавливать блокировки в таблицах, возможно, на длительное время;
• pg_monitor – право читать и выполнять различные представления и функции для мониторинга. Эта роль включена в роли pg_read_all_settings, pg_read_all_stats и pg_stat_scan_tables;
• pg_read_server_files – право читать файлы в любом месте файловой системы, куда имеет доступ postgres на сервере. А также выполняя копирование и другие функции работы с файлами;
• pg_write_server_files – право записывать файлы в любом месте файловой системы, куда имеет доступ postgres на сервере. А также выполнять копирование и другие функции работы с файлами.
• pg_execute_server_program – право выполнять программы на сервере (от имени пользователя, запускающего СУБД).

Псевдо роль public

Псевдо роль public не видна, но про неё следует знать. Это групповая роль, в которую включены все остальные роли. Это означает, что все роли по умолчанию будут иметь привилегии наследуемые от public. Поэтому иногда у public отбирают некоторые привилегии, чтобы отнять их у всех пользователей.

Роль public по умолчанию имеет следующие привилегии:

• для всех баз данных:
  • CONNECT – это означает что любая созданная роль сможет подключаться к базам данных, но не путайте с привилегией LOGIN;
  • TEMPORARY – любая созданная роль сможет создавать временные объекты во всех база данных и объекты эти могут быть любого размера;
  • CREATE (создание объектов) – любая роль может создавать объекты в этой схеме;
  • USAGE (доступ к объектам) – любая роль может использовать объекты в этой схеме;
  • USAGE (доступ к объектам) – любая роль может обращаться к таблицам системного каталога;
  • EXECUTE (выполнение) – любая роль может выполнять любую функцию. Ещё нужны ещё права USAGE на ту схему, в которой функция находится, и права к объектам к которым обращается функция.

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

  Привилегии по умолчанию

  Привилегии по умолчанию – это такие привилегии, которые добавятся к каким-то ролям на объект при его создании. Например роль Алиса хочет чтобы при создании новой таблицы доступ к ней сразу же получала роль Боб.

  Привилегии по умолчанию создаются командой ALTER DEFAULT PRIVILEGES:

  В примере выше это может быть, например таблица, функция, представление и т.п. То есть создаём мы какой-то объект из этого класса и сразу срабатывает команда выдачи привилегий: GRANT ON . .

  Аналогично можно удалять такие привилегии:

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

  Затем вам придется отдельным ролям давать эту привилегию вручную. Или можете сделать отдельную групповую роль, которая сможет выполнять функции, и включать неё другие роли.

  Практика

  Выдаем различные привилегии на объекты

  Подключимся к базе данных postgres под ролью postgres. Затем создадим роль alice и создадим схему alice. Дальше дадим Алисе привилегии создавать и использовать объекты в схеме alice. И наконец подключимся под Алисой:

  Дальше нужно вспомнить что если мы для роли создали одноимённую схему, то по умолчанию для этой роли будет использоваться эта схема.

  Под Алисой создадим 2 таблицы, затем переключимся на роль postgres и дадим Бобу право подключаться к базам:

  Теперь переключимся на роль Боб и под ним попытаемся прочитать табличку t1 в схеме alice:

  Возникла ошибка, так как у Боба нет привилегии USAGE на схему alice.

  Посмотрим какие есть привилегии у схемы alice с помощью команды \dn+:

  В поле “Access privileges” написаны построчно привилегии в следующем формате: роль=привилегии/кем_выданы.

  Привилегии сокращаются по первой букве:

  Подключимся под Алисой и попробуем от неё выдать права Бобу:

  Ошибка появилась потому-что Алиса не является владельцем этой схемы и не имеет право передавать привилегии.

  Переключимся на роль postgres и сделаем Алису владельцем схемы alice:

  Снова переключимся на Алису и выдадим права Бобу:

  Попробуем под Бобом снова прочитать табличку Алисы:

  Снова не получилось, так как у Боба нет привилегии читать (SELECT) эту таблицу.

  Посмотрим привилегии на эту таблицу с помощью команды \dp:

  Привилегии записаны в колонке “Access privileges“. Здесь пока пусто, это означает что владелец может всё, остальные ничего. А для суперпользователя проверки не выполняются, поэтому он тоже может всё. В этой колонке появится информация, если мы выдадим или заберём привилегии у кого-нибудь для этой таблицы.

  Переключимся опять на Алису, под которой выдадим привилегию SELECT на таблицу t1 для Боба. И снова проверим привилегии:

  Теперь мы видим 2 строки: для Алисы и для Боба. Привилегии сокращаются таким образом:

  Наконец Боб может выполнить запрос:

  Но вставить в эту таблицу он ничего не может, так как привилегии INSERT у Боба нет:

  Привилегии на отдельные столбцы

  Некоторые привилегии (INSERT и SELECT) можно выдавать на столбцы.

  Переключимся на Алису, и дадим бобу INSERT на колонки m и n, и SELECT на колонку m. Затем просмотрим привилегии на таблицу t2:

  В колонке “Column privileges” видны привилегии для отдельных столбцов. Видно что для столбца n Боб может только вставлять строки, а для столбца m вставлять и читать.

  Проверим привилегии Боба на практике:

  Из этого следует, что Боб смог вставить данные и в столбец n и в столбец m. А прочитать всё он не смог, так как нет прав на чтения для столбца n. Зато отдельно столбец m Боб прочитать смог.

  Если необходимо Алиса может выдать все привилегии Бобу с помощью слова all:

  Теперь Бобу доступны все действия, например, удаление строк:

  Но саму таблицу Боб удалить не сможет, так как удалить таблицу может только её владелец или суперпользователь:

  Работа с ролью public

  Алиса может выдать некоторые привилегии групповой роли public, чтобы эти привилегии появились у всех остальных:

  При выполнении команды \dp, роль public не пишется, поэтому получается такая запись =w/alice.

  Теперь Боб попробует воспользоваться привилегией UPDATE для этой таблице:

  Команде UPDATE для того чтобы что-то изменить нужно вначале это прочитать. А привилегии на чтение у Боба нет. Дадим с помощью Алисы ему это право и попробуем выполнить UPDATE ещё раз:

  Выдача права передавать привилегии

  Переключимся на пользователя postgres и создадим ещё одну роль “Чарли”:

  Боб имеет полный набор привилегий для таблицы t1. Но передать эти привилегии не может:

  Алиса может дать Бобу право передачи некоторых привилегий:

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

  Теперь Боб может передать эти привилегии для Чарли и даже дать ему также право передавать эти привилегии другим:

  Если привилегию выдаёт суперпользователь, то вместо него команда \dp выводит владельца:

  Роль может отнимать привилегии только те, которые она и выдавала. Поэтому информация о том, кто что выдавал сохраняется. Таким образом если Боб отнимет привилегии у Чарли, то у Чарли останутся те привилегии, которые ему дала Алиса (или суперпользователь).

  А если роль не выдавала какую-то привилегию, то при удалении этой привилегии никакой ошибки не будет, просто привилегии не изменятся. Например, Алиса может попытаться отобрать у Чарли право передачи привилегий на SELECT (GRANT OPTION FOR SELECT). Но это право для Чарли выдавал Боб, а не Алиса. Запрос выполнится без ошибок, но ничего не изменится:

  Ситуация описанная выше может ввести в заблуждение. Вроде право передачи привилегий отняли, а на самом деле не отняли.

  Алиса может попытаться отобрать у Боба право передачи привилегий. Но так как Боб уже воспользовался своим правом и передал право передачи привилегий ещё одному пользователю, то у Алисы ничего не получится:

  Алиса забрать это право может только каскадно, что мы и сделаем:

  В выводе можем заметить, что у Боба право передачи для SELECT исчезло, но сама привилегия SELECT осталась. А у Чарли привилегия SELECT и право её передавать исчезли.

  Дополнительно под Алисой отнимем привилегию UPDATE у Боба, тоже каскадно:

  Работа с функциями

  Теперь поработаем с функциями. Пусть Алиса создаст функцию, которая будет считать количество строк в таблице t1 и возвращать это значение (в синтаксис функции можете не вникать):

  Теперь попробуем выполнить эту функцию под Бобом:

  Боб может выполнить эту функцию, так как по умолчанию псевдо роль public может выполнять любые функции. Но так как прав на табличку t2 у Боба нету, то на команде SELECT из функции мы получили ошибку.

  Боб может в своей схеме (public) создать свою табличку t2 и выполнить функцию относительно неё. А у Алисы по умолчанию схема alice, поэтому для неё функция будет работать для другой таблицы. Вот пример:

  Алиса при создании функции может указать, что при выполнении функции она будет работать от имени владельца (Алисы), а не от имени того кто эту функцию выполняет. Для этого используется опция SECURITY DEFINER при создании функции:

  Так как функция сработала от имени Алиса, то и обратилась она к схеме alice и в ней нашла таблицу.

  Такие функции обычно создаются для контролируемого доступа. Например Бобу нельзя читать таблицу, но мы хотим дать ему право посчитать количество строк в таблице. Таким образом через функции даём доступ к объектам.

  Теперь отнимем у всех (public) привилегию выполнять функции в схеме alice:

  Команда выше удалила привилегию EXECUTE для всех существующих функций. Если Алиса создаст новую, то у public сразу появится возможность её выполнить:

  Привилегии по умолчанию

  С помощью привилегий по умолчанию можно автоматически удалять привилегии с новых объектах. Например когда Алиса будет создавать какую-нибудь функцию, то нужно чтобы сразу у роли public отнимались привилегии на её выполнение:

  Команда выше делает так, что когда Алиса создает любую функцию, привилегия FUNCTIONS сразу отнимается у public.

  Посмотреть такие привилегии по умолчанию можно с помощью команды \ddp:

  В выводе выше мы видим что для функций Алисы будут отниматься привилегии (буква X).

  Проверим. Удалим функцию и заново её создадим. И попробуем её вызвать под Бобом:

  Аналогично, с помощью привилегий по умолчанию, можно настроить чтобы Боб автоматически получал какие-нибудь привилегии. Например при создании таблиц привилегии на их чтение:

  Теперь если Алиса создаст табличку, то у Боба сразу появится привилегия SELECT на табличку:

  
  

  20 Фев 2018 21:02:09 | 1 comment

  Начало работы с PostgreSQL 10

  В данной статье я расскажу о базовых операциях PostgreSQL 10: основные команды в оболочке psql, создание и удаление базы данных, работа с табличными пространствами, создание и удаление ролей, создание простых таблиц, работа со схемами и т.д.

  Исходные данные: Debian 9.3 (Stretch), PostgreSQL 10.2
  Задача: Научиться базовым навыкам работы с PostgreSQL

  Давайте зайдем под пользователем postgres, запустим оболочку psql и попробуем поработать:

  Перед нами открылась оболочка с приглашением ввести команды:

  Первым делом давайте посмотрим информацию о версии PostgreSQL:

  Давайте пройдемся по списку наиболее нужных команд:

  1. Список баз данных.

  Список БД можно посмотреть 3-мя способами:
  Ключ -l командной строки приложения psql, метакоманда \l или select запрос к системному каталогу pg_database, например

  2. Создание баз данных.

  Базу данных можно создать 2-мя способами: Через утилиту createdb или с помощью команды CREATE DATABASE имя;
  Утилита createdb не делает ничего волшебного, она просто подключается к базе данных postgres и выполняет SQL-команду CREATE DATABASE.

  Пример этих команд и вывод списка БД:

  Так же следует упомянуть про шаблоны баз данных, при инициализации основной БД создаются так же 2 базы-шаблоны — это template0 и template1.
  По факту команда CREATE DATABASE выполняет копирование существующей базы данных. По умолчанию копируется стандартная системная база template1. Таким образом, template1 это шаблон, на основе которого создаются новые базы. Если добавить объекты в template1, то впоследствии они будут копироваться в новые базы данных.
  В системную базу template0 не желательно вносить какие либо изменения.
  В таблице pg_database есть два полезных флага для каждой базы данных: datistemplate и datallowconn.
  datistemplate — Если true, базу данных сможет клонировать любой пользователь с правами CREATEDB, то есть использовать в качестве шаблона, в противном случае, клонировать эту базу смогут только суперпользователи и её владелец.
  datallowconn — Если false, никто не сможет подключаться к этой базе данных. Это позволяет защитить базу данных template0 от модификаций.
  Для создания базы данных на основе template0 нужно выполнить из среды SQL:

  или из командной оболочки под пользователем postgres:

  Просмотр флагов datistemplate и datallowconn:

  3. Удаление баз данных.

  Тут так же как и при создании, есть 2 подхода: Через утилиту dropdb или с помощью команды DROP DATABASE имя;

  Пример:
  Пример этих команд и вывод списка БД:

  4. Работа с табличными пространствами.

  Табличные пространства в PostgreSQL позволяют администраторам организовать логику размещения файлов объектов базы данных в файловой системе. К однажды созданному табличному пространству можно обращаться по имени на этапе создания объектов.
  Табличные пространства позволяют администратору управлять дисковым пространством для инсталляции PostgreSQL. Это полезно минимум по двум причинам. Во-первых, это нехватка места в разделе, на котором был инициализирован экземпляр Pg или кластера Pg и невозможность его расширения. Табличное пространство можно создать в другом разделе и использовать его до тех пор, пока не появится возможность переконфигурирования системы. Во-вторых, табличные пространства позволяют администраторам оптимизировать производительность согласно бизнес-процессам, связанным с объектами базы данных. Например, часто используемый индекс можно разместить на очень быстром и надёжном, но дорогом SSD-диске. В то же время таблица с архивными данными, которые редко используются и скорость к доступа к ним не важна, может быть размещена в более дешёвом и медленном хранилище.

  Для создания табличного пространства используется команда CREATE TABLESPACE.
  Каталог нового табличного пространства должен существовать, быть пустым и принадлежать пользователю ОС, под которым запущен PostgreSQL.

  Создаем каталог и выставляем права:

  Подключаемся к Pg и создаем новое табличное пространство:

  Посмотреть список табличных пространств можно 2-мя способами: метакоманда \db или \db+ или select запрос к системному каталогу pg_tablespace;

  Создавать табличное пространство должен суперпользователь базы данных, но после этого можно разрешить обычным пользователям его использовать. Для этого необходимо предоставить привилегию CREATE на табличное пространство.
  Таблицы, индексы и целые базы данных могут храниться в отдельных табличных пространствах. Для этого пользователь с правом CREATE на табличное пространство должен указать его имя в качестве параметра соответствующей команды.

  Например, далее создаётся база данных в табличном пространстве fast:

  В колонке Tablespace мы видим что база test2 находится в новом табличном пространстве fast.

  Табличное пространство, связанное с базой данных, также используется для хранения её системных каталогов. Более того, это табличное пространство используется по умолчанию для таблиц, индексов и временных файлов, создаваемых в базе данных, если не указано иное в выражении
  TABLESPACE, или переменной default_tablespace, или temp_tablespaces (соответственно). Если база данных создана без указания конкретного табличного пространства, то используется пространство, к которому принадлежит копируемый шаблон.

  При инициализации экземпляра Pg или кластера Pg автоматически создаются два табличных пространства. Табличное пространство pg_global используется для общих системных каталогов. Табличное пространство pg_default используется по умолчанию для баз данных template1 и template0 (в свою очередь, также является пространством по умолчанию для других баз данных, пока не будет явно указано иное в выражении TABLESPACE команды CREATE DATABASE).

  5. Работа с ролями.

  В PostgreSQL используется концепция ролей (roles) для управления разрешениями на доступ к базе данных. Роль можно рассматривать как пользователя базы данных или как группу пользователей, в зависимости от того, как роль настроена. Роли могут владеть объектами базы данных (например, таблицами и функциями) и выдавать другим ролям разрешения на доступ к этим объектам, управляя тем, кто имеет доступ и к каким объектам. Кроме того, можно предоставить одной роли членство в другой роли, таким образом одна роль может использовать привилегии других ролей.

  Концепция ролей включает в себя концепцию пользователей (user) и групп (groups). До версии 8.1 в PostgreSQL пользователи и группы были отдельными сущностями, но теперь есть только роли. Любая роль может использоваться в качестве пользователя, группы, и того и другого.

  Роли базы данных концептуально полностью отличаются от пользователей операционной системы.На практике поддержание соответствия между ними может быть удобным, но не является обязательным. Роли базы данных являются глобальными для всего инстана Pg или кластера Pg базы данных (не для отдельной базы данных). Для создания роли используется SQL-команда CREATE ROLE, а для удаления DROP ROLE.

  5.1 Создание ролей.

  Роль можно создать/удалить 2-мя путями: через консольную утилиту createuser или dropuser и через psql с помощью CREATE ROLE или DROP ROLE.

  Давайте попробуем обя способа создания роли:

  Для просмотра списка ролей можно использовать метакоманду \du или сделать select запрос к системному каталогу pg_roles.

  Для каждой роли можно назначит определенный атрибуты, определяющие её полномочия и взаимодействие с системой аутентификации клиентов.

  Доступны следующие атрибуты (в скобках указаны столбцы из каталогу pg_roles):

  1) Право подключения (rolcanlogin):
  Только роли с атрибутом LOGIN могут использоваться для начального подключения к базе данных. Роль с атрибутом LOGIN можно рассматривать как пользователя базы данных. Для создания роли такой роли можно использовать любой из вариантов:
  CREATE ROLE имя LOGIN;
  или
  CREATE USER имя;
  или использование консольной утилиты createuser.
  Как мы уже сказали выше, команда CREATE USER эквивалентна CREATE ROLE за исключением того, что CREATE USER по умолчанию предполагает атрибут LOGIN, в то время как CREATE ROLE нет.)

  2) Статус суперпользователя (rolsuper):
  Суперпользователь базы данных обходит все проверки прав доступа, за исключением права на вход в систему. Это опасная привилегия и она не должна использоваться небрежно. Лучше всего выполнять большую часть работы не как суперпользователь. Для создания нового супер пользователя используется CREATE ROLE имя SUPERUSER. Это нужно выполнить из под роли, которая также является суперпользователем.

  3) Создание базы данных (rolcreatedb):
  Роль должна явно иметь разрешение на создание базы данных (за исключением суперпользователей, которые пропускают все проверки). Для создания такой роли используется CREATE ROLE имя CREATEDB.

  4) Создание роли (rolcreaterole):
  Роль должна явно иметь разрешение на создание других ролей (за исключением суперпользователей, которые пропускают все проверки). Для создания такой роли используется CREATE ROLE имя CREATEROLE. Роль с привилегией CREATEROLE может также изменять и удалять другие
  роли, а также выдавать и отзывать членство в ролях. Однако, для создания, изменения, удаления суперпользовательских ролей, а также изменения в них членства, требуется иметь статус суперпользователя, привилегии CREATEROLE в таких случаях недостаточно.

  5) Запуск репликации (rolreplication):
  Роль должна иметь явное разрешение на запуск потоковой репликации (за исключением суперпользователей, которые пропускают все проверки). Роль, используемая для потоковой репликации, также должна иметь атрибут LOGIN. Для создания такой роли используется CREATE ROLE имя REPLICATION LOGIN.

  6) Пароль (rolpassword):
  Пароль имеет значение, если метод аутентификации клиентов требует, чтобы пользователи предоставляли пароль при подключении к базе данных. Методы аутентификации password и md5 используют пароли. База данных и операционная система используют раздельные пароли. Пароль указывается при создании роли: CREATE ROLE имя PASSWORD ‘строка’.

  7) Игнорировать систему защиты строк (rolbypassrls):
  В дополнение к стандартной системе прав SQL, управляемой командой GRANT, на уровне таблиц можно определить политики защиты строк, ограничивающие для пользователей наборы строк, которые могут быть возвращены обычными запросами или добавлены, изменены и удалены командами, изменяющими данные. Это называется также защитой на уровне строк (RLS, Row-Level Security). Суперпользователи и роли с атрибутом BYPASSRLS всегда обращаются к таблице, минуя систему защиты строк. Более детально о RLS читайте в официальной документации или в переводе на русский.

  Атрибуты ролей могут быть изменены после создания командой ALTER ROLE. Для получения более детальной информации Вам следует обратиться к справке по командам CREATE ROLE и ALTER ROLE.

  Давайте добавим право LOGIN и CREATEDB для нашей роли utest2:

  А теперь отберем у роли utest2 право CREATEDB и добавим CREATEROLE и REPLICATION:

  Отдельно нужно упомянуть про такую вещь как членство в роли.
  Часто бывает удобным сгруппировать пользователей для упрощения администрирования привилегий: привилегии выдаются или отзываются на всю группу. В PostgreSQL для этого создаётся роль, которая представляет группу, а затем членство (membership) в этой группе выдаётся ролям
  индивидуальных пользователей.

  Сделаем групповую роль, добавим членов и создадим новую БД в табличном пространстве fast и укажем эту групповую роль владельцем БД:

  Теперь мы можем попробовать подключиться к базе group_db под пользователем utest2 из консоли:

  После ввода пароля mysecretpwd нас пустят в базу group_db. База пока у нас пустая, чуть ниже мы попробуем создать там простую таблицу.

  Так же хочу обратить внимание на такую вещь как владелец табличного пространства, чуть выше когда мы создавали табличное пространство fast, мы его создали под пользователем postgres и его владельцем стал он, см. столбец Owner при выводе информации метакомандой \db
  Поменять владельца табличного пространства можно командой ALTER TABLESPACE OWNER TO ;
  Например:

  5.2 Удаление ролей.

  Так как роли могут владеть объектами баз данных и иметь права доступа к объектам других, удаление роли не сводится к немедленному действию DROP ROLE. Сначала должны быть удалены и переданы другим владельцами все объекты, принадлежащие роли, также должны быть отозваны все права, данные роли.

  То есть наша роль является владельцем базы group_db. Чтобы решить эти проблемы нужно поменять владельца БД и только после этого удалить роль:

  Как мы видим и вывода \l+ у нашей БД group_db поменялся владелец и роль group_role1 была удалена (вывод \du).

  6. Работа с таблицами.

  Посмотрим список таблиц в БД с помощью метакоманды \dt

  Теперь удалим табличку my_first_table с помощью DROP TABLE
  Попытка удаления несуществующей таблицы считается ошибкой, поэтому рекомендуется использовать конструкцию DROP TABLE IF EXISTS

  После удаления вывод \dt скажет нам, что в БД нет таблиц.

  7. Работа со схемами.

  Схема — это способ объединения таблиц, функций, операторов, типов данных и других объектов в БД.
  Одно и то же имя объекта можно свободно использовать в разных схемах, например и schema1, и myschema могут содержать таблицы с именем mytable. В отличие от баз данных, схемы не ограничивают доступ к данным: пользователи могут обращаться к объектам в любой схеме текущей базы данных, если им назначены соответствующие права.

  Для создания схемы используется команда CREATE SCHEMA ;

  Чтобы создать объекты в схеме или обратиться к ним, указывайте полное имя, состоящее из имён схемы и объекта, разделённых точкой:

  Этот синтаксис работает везде, где ожидается имя таблицы, включая команды модификации таблицы и команды обработки данных, обсуждаемые в следующих главах. (Для краткости мы будем говорить только о таблицах, но всё это распространяется и на другие типы именованных объектов, например, типы и функции.)

  Есть ещё более общий синтаксис

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

  Создадим схему и таблицу в ней:

  Посмотрим список схем (метакоманда \dn):

  Чтобы найти нашу таблицу мы должны будем обращаться к ней по полному пути, но вывод списка таблиц через метакоманду \dt не выведет нашу новую таблицу из схемы sc_test, чтобы он вывел таблицу мы должны добавить путь поиска схемы, это делается командой:

  Чтобы не вводить SET search_path TO каждый раз мы можем задать search_path для конкретного пользователя на постоянной основе командой:

  После этого мы сможем вывести список наших таблиц из схемы public и новой sc_test:

  А что же за схема public? А дело вот в чем, до этого мы создавали таблицы, не указывая никакие имена схем, думаю Вы помните. По умолчанию такие таблицы (и другие объекты) автоматически помещаются в схему ‘public’. Она содержится во всех создаваемых базах данных. Таким образом, до того как мы указали путь поиска нашей новой схемы, команда:

  Указав путь поиска схемы мы можем выполнить DROP TABLE my_first_table; без указания схемы, но тут есть нюанс:
  ВНИМАНИЕ! Т.к. мы можем создавать одинаковые по именам объекты в разных схемах, то порядок поиска схем в путь будет иметь значение при разных операциях (создание, модификацию, удаления и др.) над объектами, вывести список путей поиска схем можно командой:

  Таким образом DROP TABLE my_first_table; первым делом удалит таблицу из схемы sc_test если она там есть, а повторный вызов DROP TABLE my_first_table; уже удалит таблицу из схемы public, при её наличии там.
  Вот поэтому если Вы используете схемы, то и все операции над объектами должны выполнятся с указанием полного имени объекта.

  Для удаления схемы нужно воспользоваться командой DROP SCHEMA ;
  Попытка удаления несуществующей схемы считается ошибкой, поэтому рекомендуется использовать конструкцию DROP SCHEMA IF EXISTS ;

  Если в схеме есть объекты, то при попытке её удаление будет выведена ошибка, пример:

  В таком случае нужно воспользоваться доп. опцией CASCADE, например:

  Как мы видим, схема sc_test и таблица my_first_table были удалены.

  На этом все, до скорых встреч.

  Если у Вас возникли вопросы или Вы хотите чтобы я помог Вам, то Вы всегда можете связаться со мной разными доступными способами.

  Состояние перевода: На этой странице представлен перевод статьи PostgreSQL. Дата последней синхронизации: 14 декабря 2021. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

  PostgreSQL — это поддерживаемая сообществом система управления базами данных с открытым исходным кодом.

  Contents

  Установка

  Установите пакет postgresql . Он также создаст системного пользователя postgres.

  Примечание: Команды, которые нужно запускать от имени пользователя postgres, в данной статье обозначены префиксом [postgres]$ .

  Для переключения в пользователя postgres можно использовать sudo:

  Смотрите также документацию sudo(8) или su(1) .

  Начальная настройка

  В первую очередь необходимо инициализировать кластер баз данных:

  По умолчанию локаль и кодировка наследуются из вашего текущего окружения (используется значение $LANG). [1] Если вас это не устраивает, вы можете прописать нужные параметры вручную с помощью опций:

  • --locale=локаль , где локаль должна быть одной из доступных системных локалей;
  • -E кодировка для выбора кодировки (должна соответствовать выбранной локали).

  Пример для русской локали:

  После инициализации на экране появится много строчек, некоторых из которых оканчиваются на . ок :

  Если вы видите подобное, значит инициализация прошла успешно. Можно вернуться в обычного пользователя, выполнив команду exit в сеансе пользователя postgres.

  Совет: Если вы хотите использовать путь отличный от /var/lib/postgres , нужно обновить файл службы systemd. Если вы помещаете его в /home , не забудьте отключить ProtectHome .

  Наконец, запустите и включите службу postgresql.service .

  Создание Вашей первой базы данных

  Совет: Если имя созданного пользователя совпадает с именем вашего пользователя в Linux, вы сможете получить доступ к базе данных оболочки PostgreSQL без явного указания имени пользователя (что весьма удобно).

  Становимся пользователем postgres. Добавляем нового пользователя базы данных с помощью команды createuser:

  Создаём новую базу данных от имени пользователя, имеющего доступ на чтение-запись, с помощью команды createdb (выполните эту команду в вашей обычной оболочке, если имя будущего владельца базы данных совпадает с вашим именем пользователя в Linux, в ином случае добавьте опцию -O имя-пользователя )

  Совет: Если вы не выдали разрешение на создание баз данных вашему свежесозданному пользователю, добавьте опцию -U postgres к этой команде.

  Знакомство с PostgreSQL

  Доступ к оболочке базы данных

  Становимся postgres пользователем. Запускаем основную оболочку базы данных, в которой мы сможем создавать, удалять базы данных/таблицы, задавать права и запускать команды SQL. Используйте опцию -d , чтобы указать название базы данных, которую вы создали (если опцию не указать, то psql попытается подключиться к базе, имя которой совпадает с именем пользователя).

  • Список всех возможных команд (например, CREATE TABLE ) для запросов
  • Подробное описание команды
  • Подключаем определённую базу данных
  • Список всех пользователей и их уровни доступа
  • Краткая информация о всех таблицах в текущей базе данных
  • Меняем пароль
  • Показать все используемые настройки
  • Выйти из psql

  Есть, конечно, много других мета-команд, но именно эти должны помочь вам начать работу. Для просмотра всех мета-команд введите:

  Дополнительные настройки

  Файл настроек сервера баз данных PostgreSQL postgresql.conf . Этот файл находится в папке данных сервера, обычно /var/lib/postgres/data . В этой же папке находятся основные файлы настроек включая и pg_hba.conf .

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

  Ограничение доступа к суперпользователю по умолчанию

  По умолчанию pg_hba.conf разрешает подключение любого локального пользователя к любому пользователю базы данных, в том числе суперпользователю. Скорее всего это не то, что вам нужно, поэтому, чтобы разрешить подключение только пользователю postgres, измените эту строку:

  Можно добавить дополнительные строки в зависимости от ваших потребностей.

  Требование пароля при входе

  Если вы выбрали scram-sha-256 , также нужно изменить /var/lib/postgres/data/postgresql.conf :

  Перезапустите службу postgresql.service и заново пропишите пароли для пользователей с помощью SQL-запроса ALTER USER пользователь WITH ENCRYPTED PASSWORD 'пароль'; .

  Доступ только через Unix-сокет

  В разделе сonnections and authentications пропишите:

  Это полностью отключит доступ через сеть. Не забудьте перезапустить службу postgresql.service для применения изменений.

  Доступ с удалённых хостов

  В разделе connections and authentications раскомментируйте или исправьте строку listen_addresses по вашему желанию на

  и внимательно просмотрите другие строки.
  Далее добавляем следующую строку в основной файл настройки проверки подлинности /var/lib/postgres/data/pg_hba.conf . (если вы планируете подключатся только со своего компьютера, то пропустите данный шаг) Этот файл определяет, каким хостам разрешено подключаться, так что будьте осторожны.

  где your_desired_ip_address — IP-адрес клиента.

  После этого необходимо перезапустить демон, чтобы изменения вступили в силу
  

  Смотрите также документацию по pg_hba.conf.

  Примечание: PostgreSQL по умолчанию использует порт 5432 для удалённого доступа. Поэтому убедитесь, что этот порт открыт и может принимать входящие соединения.

  Примечание: Ни отправка простого пароля, ни отправка md5-хэша (использованный в приведённом выше примере) через интернет не являются безопасными, если это не выполняется через защищенное SSL-соединение. Смотрите Secure TCP/IP Connections with SSL, чтобы узнать, как настроить PostgreSQL с использованием SSL.

  Если возникли проблемы взгляните на лог-файл сервера

  Настройка аутентификации через PAM

  PostgreSQL предлагает несколько методов аутентификации. Если вы хотите разрешить пользователям аутентифицироваться с их системным паролем, необходимы дополнительные шаги. Сначала вам нужно включить PAM для соединения.

  Например, та же конфигурация, что и выше, но с включенным PAM:

  Однако сервер PostgreSQL работает без прав root и не сможет получить доступ к файлу /etc/shadow . Мы можем обойти это, разрешив группе postgres доступ к этому файлу:

  Изменение стандартного каталога данных

  По умолчанию PostgreSQL настроен на использование каталога /var/lib/postgres/data для хранения всех баз данных. Для его изменения выполните следующие шаги:

  Создайте новый каталог и сделайте пользователя postgres его владельцем:

  Войдите в пользователя postgres и выполните инициализацию кластера:

  Отредактируйте службу postgresql.service , создав drop-in файл и переопределив настройки Environment и PIDFile . Например:

  Если вы хотите использовать каталог в /home , добавьте ещё одну строку:

  Изменение кодировки новых баз данных на UTF-8

  Примечание: Если вы выполнили initdb с опцией -E UTF8 или с использованием UTF-8 локали, выполнять эти шаги не нужно.

  Когда создаётся новая база данных (например, createdb blog ) PostgreSQL просто копирует шаблон базы данных. Есть два стандартных шаблона: template0 - ваниль, и template1 используемый по умолчанию. Один из вариантов изменения кодировки новой базы данных, заключается в изменении шаблона template1. Для этого, заходим в оболочку PostgresSQL (psql) и делаем вот что:

  1. Первое, мы должны сбросить template1. Шаблоны не могут быть сброшены, так что мы сначала изменим его, как обычную базу данных:

  2. Сейчас уже можно сбросить её:

  3. Создаём новую базу данных, с новой кодировкой по умолчанию из template0:

  4. Теперь снова сделаем template1 шаблоном:

  5. (Рекомендация) Документация по PostgreSQL advises рекомендует "замораживать" изменения шаблона функцией VACUUM FREEZE:

  6. (По желанию) Если вы не хотите, чтобы кто-либо подключался к этому шаблону, присвойте параметру datallowconn значение FALSE:

  Теперь вы можете создать базу данных используя стандартные команды в терминале:

  Если снова войти в PSQL и проверить базу данных, вы должны увидеть правильную кодировку новой базы данных:

  Графические инструменты

  • phpPgAdmin — Веб-интерфейс для администрирования PostgreSQL.
  • pgAdmin — Комплексный графический интерфейс для управления PostgreSQL.
  • pgModeler — Инструмент для моделирования баз данных PostgreSQL.

  Обновление PostgreSQL

  This article or section needs expansion.

  Для обновления до новой мажорной версии PostgreSQL необходима специальная процедура.

  • Следуйте официальной документации по обновлению.
  • Начиная с версии 10.0 , PostgreSQL изменил схему версионирования. Раньше мажорными были обновления с 9.x до 9.y . Теперь обновления с 10.x до 10.y считаются минорными, а мажорным является обновление с 10.x до 11.y .

  Важно: Приведённые ниже инструкции потенциально могут привести к потере данных. Не запускайте эти команды вслепую без понимания того, что они делают. Сделайте резервную копию перед началом.

  Посмотреть текущую версию можно так:

  Чтобы случайно не обновиться до несовместимой версии, рекомендуется запретить обновления пакетов PostgreSQL:

  Минорные обновления вполне безопасны. Однако если вы случайно обновитесь до другой мажорной версии, то не сможете получить доступ к данным. Всегда проверяйте домашнюю страницу PostgreSQL, чтобы знать, какие шаги требуются для каждого обновления. Чтобы узнать, почему это так, смотрите политику управления версиями.

  Есть два основных способа обновить базу данных PostgreSQL. Подробности читайте в официальной документации.

  pg_upgrade

  Для тех, кто хочет использовать pg_upgrade , доступен пакет postgresql-old-upgrade , который всегда отстаёт на одну мажорную версию от основного пакета PostgreSQL. Его можно установить параллельно с новой версией PostgreSQL. Для обновления более старых версий PostgreSQL доступны пакеты AUR: postgresql-96-upgrade AUR , postgresql-95-upgrade AUR , postgresql-94-upgrade AUR , postgresql-93-upgrade AUR , postgresql-92-upgrade AUR . Прочтите справочную страницу pg_upgrade(1) , чтобы понять, какие действия он выполняет.

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

  Когда вы будете готовы к обновлению, выполните следующие шаги:

  Остановите службу postgresql.service . Проверьте статус службы, чтобы убедиться, что PostgreSQL завершился корректно, иначе pg_upgrade не сможет отработать корректно.

  Переименуйте каталог с кластером и создайте новый каталог:

  Не забудьте прописать опции --locale , -E и/или --data-checksums по необходимости.

  Обновите кластер, выполнив эту команду (замените PG_VERSION на номер старой версии, например 12 ):

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

  Командой pg_upgrade будут созданы скрипты analyze_new_cluster.sh и delete_old_cluster.sh в каталоге /var/lib/postgres/tmp/ и выведены инструкции по их использованию.

  • analyze_new_cluster.sh генерирует статистику оптимизатора для нового кластера и должен запускаться от имени пользователя postgres . Для его работы postgresql.service должен быть запущен.
  • delete_old_cluster.sh просто удаляет каталог /var/lib/postgres/olddata и должен запускаться от имени пользователя, имеющего права записи в /var/lib/postgres (например, от имени root).

  Когда обновление будет полностью завершено, каталог /var/lib/postgres/tmp можно будет удалить.

  Выгрузка и загрузка вручную

  Ещё можно сделать что-то вроде такого (после обновления и установки postgresql-old-upgrade ):

  • В примере показано обновление с PostgreSQL 12; посмотрите в /opt/ установленную у вас версию postgresql-old-upgrade и исправьте команды по необходимости.
  • Если вы меняли файл pg_hba.conf , вам может понадобиться временно разрешить полный доступ к старому кластеру с локальной системы. После обновления не забудьте прописать нужные вам настройки в новом кластере и перезапустить службу postgresql.service .

  Решение проблем

  Ускорение мелких транзакций

  Если вы используете PostgreSQL на своей локальной машине для разработки и он медленный, то можете попробовать отключить synchronous_commit в конфигурации. Однако, не забывайте про его особенности.

  Запретить запись на диск во время бездействия

  PostgreSQL периодически обновляет свою статистику, лежащую в файле. По умолчанию этот файл находится на диске, что не даёт отдыхать (и изнашивает) жёсткому диску, заставляя его шуршать. Однако можно легко и безопасно поменять локацию файла внутрь ФС (/run) расположенной в ОЗУ с помощью такой настройки:

  Выделение прав на доступ к объектам базы данных будем рассматривать на практическом примере из этой статьи.

  Задача и требования к правам

  Имеется база данных parser, включающая следующие схемы

  • config - схема хранящая конфигурацию
  • logs - схема хранения логов
  • [project_data1, project_data2. ] - одна или более схем с данными различных проектов

  Нужно создать пользователя external_user, наделенного следующими правами

  1. Пользователь может иметь доступ только к базе данных parser. Доступ к информации других баз данных в данном кластере пользователю запрещен.
  2. Пользователь имеет доступ только к схемам config и logs. Доступ к схемам с данными проектов пользователю запрещен.
  3. В схеме config определена функция getQuery() и материализованное представление _. Пользователь имеет доступ только к этим объектам. Доступ к другим объектам схемы (таблицам, представлениям, последовательностям и т.д.) пользователю запрещен.
  4. В схеме logs от имени пользователя может выполняться создание дочерних таблиц логов и добавление в них записей. Остальные операции с таблицами запрещены.
  5. Доступ к публичным схемам information_schema и pg_catalog максимально ограничен. Имеется доступ только к объектам, доступным для выполнения функции config.getQuery()

  Реализация правил

  1. Добавляем пользователя и устанавливаем пароль для него.

  Начиная с версии 8.1 в postgresql группы пользователей и пользователи объединены в одну концепцию ролей. Это значит, что команда create role может создавать как групповые роли (группы пользователей), так и роли входа (пользователей). Выражение with LOGIN указывает на то, что мы создаем роль входа (пользователя). Второй командой мы задаем пароль для пользователя.

  Примечание. Для групповой роль также может быть назначен пароль.

  На данном шаге следует запомнить два момента.

  • пользователь создается на уровне кластера баз данных, а не отдельной базы
  • каждый созданный пользователь автоматически наделяется правами PUBLIC - эта групповая роль, которая существует в любом кластере. Для таблиц, столбцов, схем и табличных пространств роль PUBLIC не имеет никаких прав. Для баз данных роль имеет права CONNECT (подключение) и CREATE_TEMP_TABLE (создание временных таблиц). Для функций - EXECUTE (выполнение), для языков - USAGE (использование).

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

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

  и так далее. Данная информация потенциально может быть опасной. Поэтому наш следующий шаг - закрываем для созданного пользователя доступ к объектам схем

  Отступление

  Здесь важно понять механизм исключения прав. Создаваемый пользователь наследует права роли PUBLIC. Поэтому, чтобы лишить его какого-либо права нужно лишить этого права PUBLIC. Или создать другую групповую роль с нужными правами и затем предоставлять в ней членство создаваемым пользователям (в данной публикации этот вопрос не рассматривается)

  1. Закрываем созданному пользователю доступ к схемам information_schema, pg_catalog.

  На данном этапе существуют определенные тонкости со схемой pg_catalog. Во-первых, схема хранит много служебной информации, необходимой для работы пользовательских функций. Так, если закрыть для пользователя external_user доструп к pg_catalog, то вызов даже такой простой функции как getQuery() (описанной в этой статье) будет генерировать ошибку. В частности потому, что в каталоге pg_catalog хранится информация о всеъ типах данных postgresql.

  А во-вторых существует особенность доступа к объектам схемы pg_catalog. А именно при разборе sql-запроса postgresql автоматически добавляет схему pg_catalog в пути поиска. Поэтому, мы можем закрыть доступ к схеме pg_catalog и запрос типа

  подскажет нам об этом. Но автоматическое добавление pg_catalog в путь поиска позволяет нам выполнить запрос

  Поэтому, если мы хотим максимально ограничить доступ пользователя к схеме pg_catalog, воспользуемся следующими командами

  Забираем у групповой роли PUBLIC права на доступ к таблицам, представлениям и выполнению функций

  Предоставляем права пользователю external_user только для нужных объектов (в нашем примере - таблицы pg_class, pg_type)

  1. Закрываем доступ к подключению других баз данных (на примере бд other_db)
  1. Добавляем доступ к объектам схемам config и logs

  При этом, после после получения доступа к схеме, наследуя права PUBLIC стали доступны следующие операции

  • запуск всех функций, хранящихся в схеме,
  • создание временных таблиц,
  • возможность использования языков
  1. Ограничиваем доступные для выполнения функции.

  Если нужно запретить доступ к отдельным функциям, можно сделать так (на примере функции a())

  Внимание! Если функция предусматривает входные параметры, при ее указании в скобках нужно перечислить типы этих параметров.

  Если же функций много, а разрешить выполнение нужно только некоторым, делаем так (на примере функции a())

  1. Напоследок проверяем какими правами обладает наш пользовател external_user в полкюченной базе. Для этого выполняем запрос.

  Запрос работает в пределах текущей подключенной базы данных. И не информативен для роли с правами суперпользователя

  Запрос содержит следующие поля

  • subject - имя пользователя
  • schem - схема хранения объекта
  • obj - название конечного объекта на который у пользователя есть права
  • type - метка типа объекта
  • owner - владелец объекта
  • relacl - права пользователя на объект
  • public - метка принадлежности к публичной схеме information_schema или pg_catalog

  Метка типа объекта

  • r = обычная таблица,
  • i = индекс (index),
  • S = последовательность (sequence),
  • v = представление (view),
  • m = материализованное представление(materialized view),
  • c = составной тип (composite),
  • t = таблица TOAST,
  • f = сторонняя таблица (foreign)

  Права пользоватя на объект

  Записи, выводимые запросом интерпретируются так: имя_роли=xxxx -- права, назначенные роли

  =xxxx -- права, назначенные PUBLIC

  • r - SELECT ("read", чтение)
  • w - UPDATE ("write", запись)
  • a - INSERT ("append", добавление)
  • d - DELETE
  • D - TRUNCATE
  • x - REFERENCES
  • t - TRIGGER
  • X - EXECUTE
  • U - USAGE
  • C - CREATE
  • c - CONNECT
  • T - TEMPORARY
  • arwdDxt - ALL PRIVILEGES (все права для таблиц; для других объектов другие)
  • * - право передачи заданного права
  • /yyyy -- роль, назначившая это право

  Запрос возвращает только те конечные объекты (таблицы, функции. но не базы данных и схемы) у которых пользователю заданы какие-либо права. При этом, из результатов исключаются объекты, принадлежащие общим схемам information_schema и pg_catalog. Если мы хотим включить и их - нужно закомментировать условие public=false

  Как было сказано ранее, запрос возвращает права доступа пользователя к объектам текущей подключенной бд. Чтобы узнать его права для объектов другой бд кластера postgresql, сначала к этой бд нужно подключиться. Для этого будем использовать расширение postgresql dblink.

  Читайте также:

    
  • Как сделать слойки с мясом
    
  • Как сделать творожные ватрушки из бубликов
    
  • Как сделать лке
    
  • Как сделать обои на клавиатуру
    
  • Как сделать флис снова пушистым