On Wed, Apr 13, 2016 at 2:10 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Stephen Frost <sfr...@snowman.net> writes: >> On Wednesday, April 13, 2016, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> If you want to prevent that, I think it needs to be done somewhere else >>> than here. What about "ALTER OWNER TO pg_signal_backend", for instance? > >> Checks are included in that code path to disallow it. > > If there are such low-level checks, why do we need to disallow SET ROLE? > It seems like the wrong place to be inserting such defenses. > > >>> But perhaps more to the point, why is it a strange corner case for one >>> of these roles to own objects? > >> If the default roles can own objects and otherwise be used for other >> purposes then we can never, ever, be rid of any which we create. > > This argument seems quite bogus to me, because granted privileges are > pretty darn close to being objects. Certainly, if you have some > "GRANT pg_signal_backend TO joe_user" commands in a pg_dump script, > those will fail for lack of the role just as surely as ALTER OWNER > commands would. So we would need some kind of special hack in pg_dump > either way, unless we make it incumbent on users to clean up before > upgrading (which doesn't seem out of the question to me ...) > > I think you're replacing hypothetical future cruft with actual present > cruft, and it doesn't seem like a very good tradeoff.
That's my feeling as well. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
