Re: Additional role attributes && superuser review

Поиск
Список
Период
Сортировка
От Adam Brightwell
Тема Re: Additional role attributes && superuser review
Дата
Msg-id CAKRt6CRKVJLsRXsMNxJKRiADGCVv4SfAKantLiKou-2EqmxfJw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Additional role attributes && superuser review  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
All,
 
If we're going to change the catalog representation for the existing
capabilities, I'd recommend that the first patch change the catalog
representation and add the new syntax without adding any more
capabilities; and then the second and subsequent patches can add
additional capabilities.

Attached is an initial patch for review and discussion that takes a swing at changing the catalog representation.

This patch includes:

* int64 (C) to int8 (SQL) mapping for genbki.
* replace all role attributes columns in pg_authid with single int64 column named rolattr.
* update CreateRole and AlterRole to use rolattr.
* update all has_*_privilege functions to check rolattr.
* builtin SQL function 'has_role_attribute' that takes a role oid and text name of the attribute as input and returns a boolean.

Items not currently addressed:

* New syntax - more discussion needs to occur around these potential changes.  Specifically, how would CREATE USER/ROLE be affected?  I suppose it is OK to keep it as WITH <attribute_or_capability>, though if ALTER ROLE is modified to have ADD | DROP CAPABILITY for consistency would WITH CAPABILITY <value,...>, make more sense for CREATE?  At any rate, I think there is obviously much more discussion that needs to be had.
* Documentation - want to gain feedback on implementation prior to making changes.
* Update regression tests, rules test for system_views - want to gain feedback on approach to handling pg_roles, etc. before updating.

Also, what would be the community preference on tracking these attached/proposed changes?  Should I create a separate entry in the next CF for this item (seems prudent) or would it be preferred to keep it attached to the current 'new attributes' CF entry?

Thanks,
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Add shutdown_at_recovery_target option to recovery.conf
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: pg_multixact not getting truncated