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

On Fri, Jul 8, 2022 at 5:02 PM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> 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.

True. But it may not be very common for people to ALTER ROLE
[NO]INHERIT after having previously used GRANT, so I'm not sure that
it would be a big problem in practice.

> 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.

Also true.

> 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.

Could be. It's just a little hard to know what to do here, because
we've gotten opinions from only a few people, and they're all
different. I've now produced patches for what I believe to be all
three of the viable alternatives, and none of them have met with
universal acclaim:

v1: hard compatibility break, NOINHERIT no-op w/WARNING
v2: WITH INHERIT { TRUE | FALSE | DEFAULT }, DEFAULT => use rolinherit
that is current at time of use
v3: WITH INHERIT { TRUE | FALSE }, if unspecified => set grant-level
Boolean to rolinherit that is current at time of GRANT

Nobody seems desperately opposed to the basic idea of adding a
grant-level option, so probably it's OK to proceed with one of these.
Which one, though, is a bit of a puzzler.

Anyone else want to offer an opinion?

--
Robert Haas
EDB: http://www.enterprisedb.com