Re: replacing role-level NOINHERIT with a grant-level option

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

In response to

Responses

Browse pgsql-hackers by date

  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