From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Joe Conway <mail(at)joeconway(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: replacing role-level NOINHERIT with a grant-level option |
Date: | 2022-07-08 21:02:31 |
Message-ID: | 20220708210231.GA2447614@nathanxps13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 08, 2022 at 03:56:56PM -0400, Robert Haas wrote:
> For those who may not have read the entire thread, the current patch
> does not actually remove the role-level option as the subject line
> suggests, but rather makes it set the default for future grants as
> suggested by Tom in
> http://postgr.es/m/1066202.1654190251@sss.pgh.pa.us
I think this is an interesting approach, as it seems to move things closer
to the end goal (i.e., removing [NO]INHERIT), but it also introduces a
pretty significant compatibility break. With this change, you cannot keep
using [NO]INHERIT like you do today. You will also need to individually
update each GRANT. The advantage of using [NO]INHERIT as the fallback
value in the absence of a grant-level option is that users don't need to
adjust behavior right away. They can essentially ignore the new
grant-level options for now, although presumably they'd need to adjust at
some point.
IMO we should either retain compatibility for existing scripts for now, or
we should remove [NO]INHERIT completely in v16. I'm worried that keeping
[NO]INHERIT around while changing its behavior somewhat subtly is only
going to create confusion.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2022-07-08 21:05:49 | Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size |
Previous Message | Andrew Dunstan | 2022-07-08 20:20:32 | Re: SQL/JSON documentation JSON_TABLE |