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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
