On Wed, Apr 13, 2016 at 2:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Stephen Frost <sfrost@snowman.net> writes:
>> On Wednesday, April 13, 2016, Tom Lane <tgl@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
