Re: replacing role-level NOINHERIT with a grant-level option - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: replacing role-level NOINHERIT with a grant-level option
Date
Msg-id 20220708210231.GA2447614@nathanxps13
Whole thread Raw
In response to Re: replacing role-level NOINHERIT with a grant-level option  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: replacing role-level NOINHERIT with a grant-level option
List 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



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: SQL/JSON documentation JSON_TABLE
Next
From: Andrew Dunstan
Date:
Subject: Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size