Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail
| От | Andrew Gierth |
|---|---|
| Тема | Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail |
| Дата | |
| Msg-id | 87k2gr3g60.fsf@news-spur.riddles.org.uk обсуждение |
| Ответ на | Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: BUG #14242: Role with a setconfig "role" setting to a
nonexistent role causes pg_upgrade to fail
|
| Список | pgsql-bugs |
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: > Andrew Gierth <andrew@tao11.riddles.org.uk> writes: >> I don't think this is documented but it has obvious uses. Tom> Does it? For ALTER ROLE, there's actually a question that comes up not all that infrequently on irc: "how do I arrange things so that what user 'foo' does, by default, ends up owned by group role 'bar'" I'm pretty sure I have never actually suggested that anyone do it this way (because I had no idea it worked until I tried it just now), but I can see the use case. Tom> If the named role is the same as the actual role, then it's Tom> useless. If they're different, it seems at best confusing. In Tom> the context of ALTER DATABASE SET, it seems both confusing and Tom> possibly a security hazard. It _appears_ to silently fail if the user logging in is not actually a member of the specified role. I have not looked at the code. -- Andrew (irc:RhodiumToad)
В списке pgsql-bugs по дате отправления: