Document target_role param of ALTER DEFAULT PRIVILEGES
I just had a confusing moment trying to figure out why my roles
weren't creating tables the way I was expecting them to. I didn't
understand what the `target_role` parameter did. No matter how I try
to read this page, I can't see an explanation for that parameter:
https://www.postgresql.org/docs/current/sql-alterdefaultprivileges.html
I propose an explanation like the following be added to the
`target_role` parameter:
This is the role that will create objects with altered default
privileges. Note that changes in default privileges aren't
inherited, so altering the default privileges of created objects
for a parent role will not change the default privileges of
objects created by inherited roles.
On Wed, 2021-02-17 at 15:08 -0500, Jordi Gutiérrez Hermoso wrote:
I just had a confusing moment trying to figure out why my roles
weren't creating tables the way I was expecting them to. I didn't
understand what the `target_role` parameter did. No matter how I try
to read this page, I can't see an explanation for that parameter:https://www.postgresql.org/docs/current/sql-alterdefaultprivileges.html
I propose an explanation like the following be added to the
`target_role` parameter:This is the role that will create objects with altered default
privileges. Note that changes in default privileges aren't
inherited, so altering the default privileges of created objects
for a parent role will not change the default privileges of
objects created by inherited roles.
+1. I cannot count the number of times I have seen people confused by that.
Suggested patch attached.
Yours,
Laurenz Albe
Attachments:
0001-Clarify-docs-for-ALTER-DEFAULT-PRIVILEGES.patchtext/x-patch; charset=UTF-8; name=0001-Clarify-docs-for-ALTER-DEFAULT-PRIVILEGES.patchDownload+7-1
On Thu, Feb 18, 2021 at 08:16:13AM +0100, Laurenz Albe wrote:
On Wed, 2021-02-17 at 15:08 -0500, Jordi Gutiérrez Hermoso wrote:
I just had a confusing moment trying to figure out why my roles
weren't creating tables the way I was expecting them to. I didn't
understand what the `target_role` parameter did. No matter how I try
to read this page, I can't see an explanation for that parameter:https://www.postgresql.org/docs/current/sql-alterdefaultprivileges.html
I propose an explanation like the following be added to the
`target_role` parameter:This is the role that will create objects with altered default
privileges. Note that changes in default privileges aren't
inherited, so altering the default privileges of created objects
for a parent role will not change the default privileges of
objects created by inherited roles.+1. I cannot count the number of times I have seen people confused by that.
Suggested patch attached.
I see how people can be confused. I wrote this patch, which I think is
simpler than the previously posted one.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
Attachments:
role.difftext/x-diff; charset=us-asciiDownload+5-1
On Wed, 2023-11-01 at 13:09 -0400, Bruce Momjian wrote:
On Thu, Feb 18, 2021 at 08:16:13AM +0100, Laurenz Albe wrote:
On Wed, 2021-02-17 at 15:08 -0500, Jordi Gutiérrez Hermoso wrote:
I just had a confusing moment trying to figure out why my roles
weren't creating tables the way I was expecting them to. I didn't
understand what the `target_role` parameter did. No matter how I try
to read this page, I can't see an explanation for that parameter:https://www.postgresql.org/docs/current/sql-alterdefaultprivileges.html
I propose an explanation like the following be added to the
`target_role` parameter:This is the role that will create objects with altered default
privileges. Note that changes in default privileges aren't
inherited, so altering the default privileges of created objects
for a parent role will not change the default privileges of
objects created by inherited roles.+1. I cannot count the number of times I have seen people confused by that.
Suggested patch attached.
I see how people can be confused. I wrote this patch, which I think is
simpler than the previously posted one.
Oh, I had forgotten about this patch. I like your version better.
There is another patch in the current commitfest that addresses a similar
problem, triggered by another complaint:
https://commitfest.postgresql.org/45/4633/
That patch does not cover role membership. Perhaps you could adopt that
patch and merge the information from your patch into it.
Yours,
Laurenz Albe
On Wed, Nov 1, 2023 at 09:31:52PM +0100, Laurenz Albe wrote:
On Wed, 2023-11-01 at 13:09 -0400, Bruce Momjian wrote:
On Thu, Feb 18, 2021 at 08:16:13AM +0100, Laurenz Albe wrote:
On Wed, 2021-02-17 at 15:08 -0500, Jordi Gutiérrez Hermoso wrote:
I just had a confusing moment trying to figure out why my roles
weren't creating tables the way I was expecting them to. I didn't
understand what the `target_role` parameter did. No matter how I try
to read this page, I can't see an explanation for that parameter:https://www.postgresql.org/docs/current/sql-alterdefaultprivileges.html
I propose an explanation like the following be added to the
`target_role` parameter:This is the role that will create objects with altered default
privileges. Note that changes in default privileges aren't
inherited, so altering the default privileges of created objects
for a parent role will not change the default privileges of
objects created by inherited roles.+1. I cannot count the number of times I have seen people confused by that.
Suggested patch attached.
I see how people can be confused. I wrote this patch, which I think is
simpler than the previously posted one.Oh, I had forgotten about this patch. I like your version better.
There is another patch in the current commitfest that addresses a similar
problem, triggered by another complaint:
https://commitfest.postgresql.org/45/4633/That patch does not cover role membership. Perhaps you could adopt that
patch and merge the information from your patch into it.
Agreed. I found this doc report from 2020 with the same confusion about
what target_role means:
/messages/by-id/160003085417.31338.6391977653235501273@wrigleys.postgresql.org
I will apply my patch tomorrow/Friday and then work on the commitfest
one.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
On Thu, Nov 2, 2023 at 09:51:58PM -0400, Bruce Momjian wrote:
On Wed, Nov 1, 2023 at 09:31:52PM +0100, Laurenz Albe wrote:
There is another patch in the current commitfest that addresses a similar
problem, triggered by another complaint:
https://commitfest.postgresql.org/45/4633/That patch does not cover role membership. Perhaps you could adopt that
patch and merge the information from your patch into it.Agreed. I found this doc report from 2020 with the same confusion about
what target_role means:/messages/by-id/160003085417.31338.6391977653235501273@wrigleys.postgresql.org
I will apply my patch tomorrow/Friday and then work on the commitfest
one.
Okay, patch applied to all supported version. I will now work on the
similar commitfest item.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
On Fri, 2023-11-03 at 09:53 -0400, Bruce Momjian wrote:
On Thu, Nov 2, 2023 at 09:51:58PM -0400, Bruce Momjian wrote:
On Wed, Nov 1, 2023 at 09:31:52PM +0100, Laurenz Albe wrote:
There is another patch in the current commitfest that addresses a similar
problem, triggered by another complaint:
https://commitfest.postgresql.org/45/4633/That patch does not cover role membership. Perhaps you could adopt that
patch and merge the information from your patch into it.Agreed. I found this doc report from 2020 with the same confusion about
what target_role means:/messages/by-id/160003085417.31338.6391977653235501273@wrigleys.postgresql.org
I will apply my patch tomorrow/Friday and then work on the commitfest
one.Okay, patch applied to all supported version. I will now work on the
similar commitfest item.
Thanks!
Laurenz Albe