Re: role self-revocation
Stephen Frost <sfrost@snowman.net>
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Joshua Brindle <joshua.brindle@crunchydata.com>, Mark Dilger <mark.dilger@enterprisedb.com>, Andrew Dunstan <andrew@dunslane.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2022-03-07T19:17:05Z
Lists: pgsql-hackers
Greetings, * Tom Lane (tgl@sss.pgh.pa.us) wrote: > Stephen Frost <sfrost@snowman.net> writes: > > * Tom Lane (tgl@sss.pgh.pa.us) wrote: > >> Agreed, this is not something to move on quickly. We might want > >> to think about adjusting pg_dump to use explicit GRANTED BY > >> options in GRANT/REVOKE a release or two before making incompatible > >> changes. > > > I'm with Robert on this though- folks should know already that they need > > to use the pg_dump of the version of PG that they want to move to and > > not try to re-use older pg_dump output with newer versions, for a number > > of reasons and this is just another. > > Yeah, in an ideal world you'd do that, but our users don't always have > the luxury of living in an ideal world. Sometimes all you've got is > an old pg_dump file. Perhaps this behavior wouldn't mess things up > enough to make the restored database unusable, but we need to think > about (and test) that case while we're considering changes. I agree it's something to consider and deal with if we're able to do so sanely, but I disagree that we should be beholden to old dump files when considering how to move the project forward. Further, they can surely build and install the version of PG that goes with that dump file in a great many cases and then dump the data out using a newer version of pg_dump. For 5 years they could do that with a completely supported version of PG, but we've recently agreed to make an effort to do more here by supporting the building of even older versions on modern systems. Thanks, Stephen
Commits
-
Make role grant system more consistent with other privileges.
- ce6b672e4455 16.0 landed
-
Ensure that pg_auth_members.grantor is always valid.
- 6566133c5f52 16.0 landed
-
Remove the ability of a role to administer itself.
- 79de9842ab03 15.0 landed
-
Add tests of the CREATEROLE attribute
- e9d4001ec592 15.0 landed
-
Replace explicit PIN entries in pg_depend with an OID range test.
- a49d08123599 15.0 cited
-
Shore up ADMIN OPTION restrictions.
- fea164a72a7b 9.4.0 cited
-
Add pg_has_role() family of privilege inquiry functions modeled after the
- f9fd1764615e 8.1.0 cited
-
Align GRANT/REVOKE behavior more closely with the SQL spec, per discussion
- 4b2dafcc0b1a 8.0.0 cited