| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Ted Yu <yuzhihong(at)gmail(dot)com>, Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)ru>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX |
| Date: | 2023-06-20 17:42:10 |
| Message-ID: | 20230620174210.GB471329@nathanxps13 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jun 20, 2023 at 09:16:59AM -0700, Jeff Davis wrote:
> On Tue, 2023-06-20 at 14:26 +0900, Michael Paquier wrote:
>> TBH, I have a mixed feeling about this line of reasoning because
>> MAINTAIN is much broader and less specific than TRUNCATE, for
>> instance, being spawned across so much more operations.
>
> ...
>
>> Some users may find that surprising as they
>> used to have more control over these operations as owners of the
>> relations worked on.
>
> It seems like the user shouldn't be surprised if they can carry out the
> action; nor should they be surprised if they can't carry out the
> action. Having privileges revoked on a table from the table's owner is
> an edge case in behavior and both make sense to me.
>
> In the absense of a use case, I'd be inclined towards just being
> consistent with the other privileges.
Agreed, I think we should make MAINTAIN consistent with the other grantable
privileges.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2023-06-20 17:46:10 | Re: remap the .text segment into huge pages at run time |
| Previous Message | Nathan Bossart | 2023-06-20 17:40:32 | Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX |