Re: Role Self-Administration

Greetings,

* Mark Dilger (mark(dot)dilger(at)enterprisedb(dot)com) wrote:
> > On Oct 7, 2021, at 9:05 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > I don't think the spec supports any of the three rules you list.
>
> And I'm not seeing that it prohibits any of them.

I don't agree that we can decide to have random statements which are
defined explicitly in the standard to do X end up doing X+Y, simply
because the standard didn't explicitly say "you can't have Y happen when
X does".

I hate to think what the standard would look like if it was required
that every possible thing that could happen when a statement is run had
to be explicitly listed as "don't have this happen when this command
runs" except for the few things that the standard defines the statement
to do.

The argument being presented here would allow us to have INSERTs perform
CREATE ROLEs, or have DELETEs also TRUNCATE other tables that aren't
even mentioned in the command, and still claim to be in compliance with
the standard.

Extending the language with new syntax and then deciding how that new
syntax works is one thing, but taking existing, defined, syntax and
making it do something other than what the standard is saying does, imv
anyway, go against the standard. Sure, we've gone against the standard
at times for good reasons, but I don't agree that this is anywhere close
to a reasonable case for that.

Let's just invent some new syntax for what you're looking for here that
works the way you want and doesn't have this issue. As I said before, I
agree with the general usefulness of this idea, and I can even generally
get behind the idea of role ownership to allow us to do that, but we
can't make 'DROP ROLE bob CASCADE;' do it, it needs to be something
more, like 'DROP ROLE bob CASCADE OBJECTS;' or such.

I really don't understand why there's so much push back to go in that
direction. Why must 'DROP ROLE bob CASCADE;' drop all of bob's objects
and roles "owned" by bob?

Thanks,

Stephen