Greetings, * Mark Dilger (mark.dil...@enterprisedb.com) wrote: > > On Oct 7, 2021, at 9:05 AM, Stephen Frost <sfr...@snowman.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
signature.asc
Description: PGP signature
